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[57] ABSTRACT 

A computer program specification system is disclosed 
for interactively creating program specifications re- 
sponsive to user input. The system includes facilities to 
respond to changes, supplied interactively, to a pro- 
gram specification without recompiling the program 
specification, and immediately to display a simulation of 
those changes. The system also supports the merging of 
actors, which are software objects comprising data 
structures and program procedures, and the merging of 
actor behavior. A user of the system creates a program 
specification by specifying actors for use in a plurality 
of scenarios, and operational steps of the plurality of 
scenarios. The system executes operational steps of a 
scenario to evaluate the consistency of the specification 
and actor data. Execution of an operational step com- 
prises simulating the operational step upon the occur- 
rence of predetermined conditions and storing the re- 
sults of the simulation. Execution of a sequence of oper- 
ational steps can be reversed or undone in order to 
insert a change in the specification prior to resimulating 
the undone sequence or other related sequences. Simu- 
lation of an operational step comprises one or more of: 
executing communications among actors, asserting rela- 
tionships among actors, executing a logical or arithmeti- 
cal computation for actors or requesting input of a deci- 
sion choice. 
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FIG. 3 
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330— (c:3, user, term, (c:2 « c:3), (), (keyboord-entry login-nome), "user types 
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380- (c:5.1, term, comp, (c:5 b « c:5.1), (), (doto-send entry-streom), "terminol 
tronsmits keyboord input") 
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of a system, the developer must stop the simulation, 

INTERACTIVE COMPUTER PROGRAM ma ke the desired change, recompile the program to be 

SPECIFICATION AND SIMULATION SYSTEM simulated, and then start the simulation from the begin- 
ning. Thus, a developer cannot immediately view the 

CROSS-REFERENCE TO RELATED 5 results of a change, and this process of making a change 

APPLICATION j s s |ow, resulting in an inefficient use of developer time. 

This application relates to an application by P. T. Z. A problem of the prior art, therefore, is that there is 

Kapauan entitled "Order Independent Rule-Based Pro- not an efficient arrangement for specifying software 

gram Specification System," Ser. No. 07/510,378, filed that does not require extensive programming knowl- 

on Apr. 17, 1990, now abandoned and assigned to the 10 edge by a user. 

same assignee as this application. SUMMARY OF THE INVENTION 

TECHNICAL FIELD A speci f IC embodiment of the present invention for 

This invention relates to a method and apparatus for solving the above problem is the Graphical Recording 

developing program specifications for computer sys- 15 and Animation of Specifications (GRAS) system. The 

terns and telecommunications systems. GRAS system is used to graphically record, simulate 

BACKGROUND OF THE INVENTION (animate) and refine program specifications intcrac- 

tively. This system provides for the design of program 

The development of complex computer programs or specifications through examples, 
software systems for controlling operations of comput- 20 The objective of the GRAS system is to provide a 
ers and telecommunication systems requires a large facility for engineers with little programming knowl- 
work effort. Computer programmers (software devel- edge to easily create program specifications. This objec- 
opcrs) expend a great deal of effort tn designing, coding tivc & accomplished by providing a user-friendly en vi- 
and testing complex software systems. The process of ron ment based on a familiar model. The GRAS system 
designing, writing and coding, called a software devel- 25 . $ basfid ^ a yidco studiQ mcta hor (VSM)( whercin the 
opment cycle, often requires several years for a com- crcation of a spccirication for a program is ^gous t0 
plex system. Over the years software developers have creati directi vidcotaping , and editing a Ia *. ^ 

f Vn'S* ^ 0rtCn ^ * video studio metaphor exiends the theater metaphor 

smaller fraction of the cycle is spent testing software . ^^ ar ^ m : nn K », M h MMA i 

In spite of advances in software technology, the de- ^'ation-Laura Gould and Wham Fmier. Little 
velopment of increasingly complex computer software Programmmg loiowledge is required to create specifica- 
and software-driven systems remains difficult. Tliis tions using a VSM based system. Advantageously, corn- 
difficulty has increased the importance of an efficient, 35 P leJutv 15 rcduced In thc software specification process 
low error-rate software design process. Design of speci- becausc e n S>*eer can concentrate on how an object 
fications is an important first step to facilitate the devel- s y stcm should 0I««"e with less attention being devoted 
opment of software. Specifications contain require- to the operation of the specification system, 
ments that software systems must meet, and specify A ^ of the GRAS svstcm supplies input for a 
how the systems must operate. These specifications, like 40 " ta Pe" which is a software recording of a specification, 
the software systems they describe, have become in- The GRAS svsteTn creatcs a ^P* °y recording steps of 
creasingly difficult to generate. One reason for this is a group of example scenarios and by deriving additional 
the detailed knowledge of the software environment generic rules for these example scenarios. A step sped- 
that is required to generate the specification. fies an interaction between actors of a tape simulated via 

Software simulators are used by software developers 45 message passing. (As discussed hereinafter, the concept 

to ease the difficulty of developing and testing specifica- of "actor" is known in the field of artificial intelligence), 

tions by modeling the operation of software systems. Actors are computer software constructs comprising 

Based on input about a system, simulators generate a data » and procedures that manipulate the data. Actors 

program that models the operation of the system. Al- used by GRAS also have a knowledge base and a his- 

tbough simulators aid in the development of specifica- 50 torv of changes to the data. Actors represent physical 

tions, they present several problems. First, simulators components of system, such as a telephone or telephone 

are not based on a simple, familiar model; programming switching system or software components such as a 

knowledge of at least the simulator "language** is re- process or a database, or persons, agents interacting 

quired to generate an adequate model of a system. Not with the system. A user of GRAS records a step of an 

only must a developer be concerned with how a simu- 55 example scenario by specifying a sender and receiver 

lated system should operate, but, additionally, he/she actor for the step, a message to be sent from the sender 

must devote a significant amount of thought to develop- actor to the receiver actor, and any conditions that must 

ing the simulation program. Thus, complexity is added be present in the system before the step is executed, 

to the software specification process. Each step is recorded as a rule on the tape and is exe- 

Next, simulators represent independent parts of a 60 cuted in the example scenario. A user can interactively 
system as separate entities, requiring specific inputs and refine the tape by executing example scenarios (playing 
producing specific outputs. This is a problem because the tape), making corrections, adding new steps, or 
these entities cannot interact with each other (be "con- creating new example scenarios, 
nected") unless the inputs and outputs correspond, and The design of a computer login sequence for a corn- 
often they do not. Thus, a developer using a simulator 65 puter system provides a simple example of the use of 
cannot always see a total integration of system parts. GRAS. The actors for a computer login sequence are a 

Finally, if, during a simulation, a developer discovers computer, a terminal and a user. Assume that an engi- 

an error or wants to change some part of the operation neer using GRAS would like the computer login se- 



03/13/2004, EAST Version: 1.4.1 



5,247,651 

3 4 

quence to be implemented as follows: (1) the computer can generate a specification without a detailed knowl- 
activates the sequence by sending a "send login" re- edge of programming or of the system, 
quest message to the terminal; (2) the terminal then A SoftCoder module of GRAS provides the mecha- 
displays a login prompt to the user; (3) the user sends a nism to record (enter), play (execute), and undo (re- 
login name to the terminal via a keyboard entry; (4) the 5 verse execution) example scenarios of the specification, 
terminal transmits the login name to the computer, (5) The SoftCoder is a virtual machine that processes a 
the computer sends a message to the terminal to initiate "(video) tope program," describing rules of behavior 
a password entry procedure; (6) the terminal displays a between actors, and produces a "tape scenario" corn- 
password prompt to the user; (7) the user sends a pass- prising a complete trace of the specification program 
word to the terminal via a keyboard entry; and (8) the 10 execution. Each step in a tope program comprises a set 
terminal sends the password to the computer. of arithmetic and/or logical computations, actor data. 

To supply input for a tope of the computer login messages representing communications between 

sequence, a GRAS user begins by specifying the first * ctors that MC reversible by "undoing" a step, thus 

step of the sequence. In so doing, the user is specifying providing users with a mechanism for interactively 

the first step of an example scenario; a complete pro- 13 changing parts of the specification. Advantageously, a 

gram is specified by a plurality of example scenarios. To user efficiently correct errors and make changes to 

specify step (1) above, the user first specifies the sender a . sp^cation during a simulation and immediately 

actor as the computer, the receiver actor as the termi- VICW tne re 51 " 15 - 

nal, and the message passed as "send login/' This step * management of visual object networks (MoVon) 
would be graphically displayed for the user while being 20 modu * c md " ^ame (AF) module of GRAS 
recorded as part of the example scenario. To specify P™de • mechanism for the merging of actors and 
step (2) above, the user specifies the sender actor as the ac # ,or ^vior, thus allowing a user to view a totally 
terminal, the receiver actoTas the user, and the message specification. Advantageously GRAS pro- 
passed as "please login:" Again, this step would be „ «d« . fccility for users to view the integration and 
ii £■ i j r *u vi u • j-j *3 combined operation of different parts of a specification, 
graphxally delayed for the user while being recorded. ^ me( £ d of imeractively ^ cating salifications 
The user proceeds to specify the remaimng steps of the for a ^ ^ ac| * £ % ^ 
sequence in the same manner. After recording the se- . Qf ^ in TCS ^ to receiving actor data 
quence, the user plays the tape, thus graphically simu- vja an ^ devicC( such k ^ or m0USC( and 
Unng the computer login sequence. FIG. 5 illustrates a ^ stQri the act0f da|a Spccifying actors comprises cre . 
GRAS graphical display of the entire computer login ating new act0fS( ^ting previously created actors, 
sequence. and m odifying actor data. In response to receiving op- 

At any time during recording, the user can stop re- erational Mps v ia the input device, the systems stores 

cording and play the tape to graphically simulate the thc $tcps for subscqucnt execution. These steps com- 

steps already specified. If a step is incorrect the user can 35 prise communications among actors, relationships 

interactively "undo" the step, change actors, change , ogicaJ or arithmetic computations for 

the message, or change preconditions for the step, and ^ c actorSr ^ decision points for the plurality of tope 

then play the step again. This permits interactive editing scenarios. To evaluate the consistency of a specifica- 

and refinement of a program specification. ^n, a first tape scenario is executed in response to 

The above example illustrates the operation of the 40 receiving a first decision choice via the input device, 

invention. In accordance with the principles of this Execution of the first tape scenario comprises simulat- 

invention, a computer, responding to interactive user ing steps c f a scenario upon the occurrence of a set of 

input, creates a program specification. In a departure predetermined conditions and storing the results of the 

from the art, the program specification system provides simulation. Simulating comprises one or more of the 

facilities to respond to changes, supplied interactively, 43 following: asserting relationships among actors, execut- 

to a specification, without recompiling the specifiation j n g communications among actors, executing a logical 

program, and immediately display a simulation of those Q r arithmetic computation for actors, or requesting 

changes. Advantageously, a developer can create a mpm 0 f a decision choice. Finally, additional tope see- 

specification more rapidly and more efficiently, and narios are executed sequentially in response to receipt of 

with little knowledge of the operation of the simulation 50 alternate decision choices via the input device, 

system. The system is arranged to stop a simulation after a 

In a further departure from the art, the invention specified operational step in response to an instruction 

supports the merging of actors, which are software received via the input device during simulation of the 

objects comprising data structures and program proce- operational steps. In response to receipt of input data, 

dures, and the merging of actor behavior. The idea of an 55 the system then stores additional actor data and addi- 

"actor" is well-known concept from artificial intelli- tional operational steps, and the simulation is resumed, 

gence; see for example Gul Agha, Actors: A Model of with the additional steps and actors included. Advanta- 

Concurrent Computation in Distributed Systems, MIT geously, a user can interactively make additions to a 

Press, 1986. Advantageously, this merging allows de- specification and immediately view the results of those 

velopers to view a total integration of program system 60 additions. 

parts. Operational steps are reversible ("undoable") during 

GRAS, an exemplary embodiment of the invention, is a simulation. An undone step is modified and the simula- 

an object-oriented, knowledge-based visual program- tion is resumed, re-simulating the undone steps in their 

ming system based on the VSM. GRAS uses the input modified versions. Advantageously, a user can interac- 

of a user to create a visual simulation and specification 65 lively make changes to a specification and immediately 

database of the system, and builds upon that database as view the results of those changes, 

more detailed input is received. Advantageously, be- Simulating the operational steps comprises automat i- 

cause the VSM provides a familiar, simple model, a user cally identifying decision choices for which a program 
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path has not been specified, and notifying a user of these _. _ 
choices and incomplete program paths. Also, simulating Glossary of Important Terms 
the operational steps comprises checking whether an BackStage: each actor in a given Production Studio is 
actor's data is complete and notifying a user of incom- known by its unique address (e.g. birth name and ad- 
plete data. Advantageously, a user can simulate an in- 5 k*' 8 ' security number). The set of all actors 
complete specification. available at one time is called the BackStage. Each 
A plurality of levels of display are available in the actor has onl y one in this context, even if it is 
system, with each level corresponding to a level of m md « physically shared between 
detail of the simulation. A user may specify a different *** "P" currently available in the ORAS system. Be- 
set of levels for each operational step. When executing 10 £*f „ wh,le 8 « b«"8 recorded, one or more 
a tape scenario, the ORAS system displays results only Stu *° Rooms can be chosen. Each Studio Room can be 
for those steps which are at a level which is a member to u record 8 ^ fferent P«P«*ve or view, each 
of the set. even .hough it simulates all steps of other ?" d, ° *"* 8 rec f ? lng cam . era - Acto " " e chosen/ " d - 

spectfied levels. Advantageously, a user can interac- „ dc l ° r wnJ ? re ^ rd " g ' 8s , aeedcd ; 

J[ , c _ . '* . 4 . 15 Frame: a frame is a flexible data structure used for 

dvely refine a spectf.cat.on by adding more detailed M<jTmatioD classif5cation or concepts organiMtiorl . The 

steps to the spec.ficat.on as more information becomes te ^ rf (he data ^ fr * m ^ fac , tha , 

avaUaWe. and viewing the results of simulating the more jt ^ dynamically extensible and redefinable. 

™ C P« .... „ Frame systems are usually equipped with a hierarchical 

The GRAS system permits simulation of two or more 20 inherit ance mechanism based on the IS-A or AKO(A 

operational steps concurrently. If any actor is common ki ndK >r) classification scheme. 

to both concurrent program paths, the system ensures Actor: ^ actor is ^ extension of an object. An object 

that other actors accessing data of the common actor do comprises data and procedures that manipulate the data, 

not access the same data at the same time, The system An actor encapsulates data as an object (using slots and 

can delay simulation of an operational step of the tape 2 $ values). However, the encapsulated set of slots as well 

scenario for a prespecified time or for a time computed as the actual values of these slots can vary with time and 

during simulation from the time of simulation of a first these variations are reversible. From the metaphorical 

operational step, or delay simulation of a first opera- view, an actor can learn and forget categories of infor- 

tional step until a second operational step has been simu- mation and information values as well as remember 

lated. The GRAS system may further execute a called 30 what information it had at any specific moment in its 

tape program as part of execution of a calling tape pro- life. To implement this feature, an actor keeps a history 

gram and return to the calling tape program following of changes made to its data space (slots and values). An 

the execution of the called tape program. The system actor is able to produce a symbolic description of its 

may also insert a copy of a subset of a second tape pro- current data-space at any time (self description) and/or 

gram after the simulation of a first operational step of a 55 a symbolic description of the difference between its 

first tape program and prior to the simulation of a sec- symbolic data-spaces at two different times; these de- 

ond step of the first tape program. Advantageously, scriptions are maintained in a history by the implemcn- 

concurrent simulation of operational steps gives a realis- tation of the actor system. 

tic view of system operation resulting in consistent Implementation of Actors: the implementation of 

specifications. 40 actors far GRAS supports the following capabilities: an 

actor's generic properties include its ability to learn a 

BRIEF DESCRIPTION OF THE DRAWING new role, to forget a previous role, to transform existing 

The invention will be better understood from the information, to acquire new information, to communi- 

following detailed description when read with refer- catc information to other actors, to be (optionally) visi- 

ence to the following drawing in which: 45 b j c » var ? ous costumes (visual representations are op- 

FIG. 1 is a block diagram of the GRAS system archi- tiona] attributes of such actors). An actor can be shared 

tectural structure reused, merged, divided, organized as a combination of 

FIG. 2 is a flow diagram of a computer login se- ac | ors c>r decomposed into sub-actors Based on a logi- 

quence to be specified using the GRAS system. „ C * %!?* metlC « Uc " latl0n - thc ro,e of 40 actor can * 

FIG. 3 is a d£a diagram illustrating the contents of a 50 ™dified by a f?**" °"'f * > « ^ ♦ 
. . - . * . i ■ Actor knowledge base: the set of an actor's attributes 

sc "?L Ior . Spcc ? ng . . com P ute 5 IO « In . sequence. (s1qU and values) that 

can be accumulated (learned) and 

a- and 5 are diagrams illustratmg the GRAS rmoved (f tten) constjtute M actor . s dynamk : pri . 
system display after simulating the computer login se- vftle ^ ^ of thc knowledge base is 

'"5.?^. , „„ _ ... 33 defined here in the following sense: The knowledge is 

FIGS. 6-28 are flow diagrams illustrating various not directIy accessible t0 (and not sha red with) other 

functions of the GRAS system. Actors infonnation is on | y accessible to other 

FIGS. 29-32 are diagrams illustrating GRAS system wno CJ , phci ,y reque st it during a transaction. An 

simulation modes m terms of the Video Studio Meta- actor knowledge base is defined using actor environ- 

phor(VSM). 

60 ment, an implementation of the actor data-space de- 

DETAILED DESCRIPTION scription D(A,t). 

Actors and inheritance: the AKO relation used in the 

The Graphical Recording and Animation of Specifi- frame description of actors is internally used to provide 

cations (GRAS) system is based upon several key con- frame classification. In GRAS, however, the AKO 

cepts that are described in a special terminology, useful 65 relation is not directly accessible to the user. The avail- 

for this type of system. An understanding of these terms able set of operations on actors is sufficient for users to 

is helpful in understanding the GRAS system. The spc- design actor oriented models of communication without 

cial terms used in GRAS are defined below. requiring multiple inheritance. Inheritance is only pro- 
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vided to the user of GRAS if it can be semi-autoxnati- Actors and Objects: actors do not have message pass- 

cally maintained by the actor system. ing methods explicitly defined, instead they inherit from 

Actor Merging and Fusion: additional flexibility is the Actor class the basic methods to learn, forget attri- 

provided in the actor model by the concept of Merging butes and behaviors, to send and process communica- 

and its implementation. Various levels of Merging are 5 tions, and to simulate behaviors. Instead of originally 

possible as follows: inheriting from various (predefined) classes, actors can 

1) r«iaming:thestagenamcofanactorisreplacedby be progressively defined and refined, new information 
a new stage name, the actor uses the same set of rules; slots and values being added, changed or removed as 
the stage-name is the name used to refer to this actor in ****** From the metaphorical view, an actor's "per. 
the execution of a specific scenario; 10 sonality" or general behavior xs not known a-pnon but 

2) address change: the address (identification) of the * gathered a-posteriori from all the tapes where this 
actor is changed; if the new address is that of an existing actor is playing. Actors do not exist by themselves as 
actor, a merge is actually performed; traditional objects with a predefined set of behaviors. 

3) merge: actor A is merged with another existing They exist in the context of vanous scenarios where 
actor, B; the type of merge can vary continuously from 15 vanous behaviors are made available for them. 

the resulting new actor C becoming B (attributes and Audition: refers to the process used to se ect an actor 

relations) to C becoming A or C becoming a combina- to pcrforma given task. An actor can be selected for its 

tion of attributes and relations from A and B; in all whe ' c * » defmcd « * functl0n of the 

cases, the resulting actor C inherits all rules from both , n T^/*^ ? ^ ^TTf 

A and B; the applicability of these rules is a function of 20 de ** ™* a ? or and of the current set of 

Cs resulting attributes and of preceding rules; if certain ^ ° * r 

rules never apply, they may be removed; some of the ^ P roces f °f audition (audit) involves identify, 

rule maintenance can be automated based on logical m W 0 *™" match to 

analysis and reachability algorithms; 25 Creation? is the process of creating a new actor fol- 

4) fusion: the actor is fully added and fused with a , owi a ^ ^ ^ A new J tor ^^ tT}lcme 
second actor (C = A + B); thus a case of a complete h ^ ^ mjtia] attributcs malching thc description, 
merge; the result is a new actor that is used wherever A Cfeation tion may resuh in the CTeation of a ^ 
either actor was used before the fusion took place; q( act0fS a])d rdations (an ^ nctwork) , If lhe ^nt 
therefore the new actor inherits all the ru es from both 3Q description h emptV( a minimum act0 r data-structure is 
actors, the new actor is also a "monster' in the sense CTtaiedt if , hc actor talent description contains or evalu- 
that it also inherits all the relationships and components ates to a 5pccific actor address (identification) and an 
from both actors; for example when fusing a terminal actor exists at this address , this actor is reU sed. 
with a plain old telephone service (POTS) phone, the Destruction: is the action of removing an actor ad- 
resulting "monster" is a phone-terminal that has both 35 dress from an actor pool, stopping its history, removing 
the features of a terminal and a POTS phone; this "mon- the actor data-structure, relations to other actors and 
ster M can be interpreted as either a terminal with POTS (optionally) the actor visual displays from devices 
phone features or a POTS phone with terminal features; whcre it ^ currC nt|y visible. This process may or may 
this feature is useful when experimenting with new not j nvo lve "garbage collection" (removal of obsolete 
designs. 40 data) depending on the implementation. 

Merging two actors can result in merging two net- Replacement: when an actor is unable to complete a 

works of actors and their relationships. A network of a replacement actor may be selected in place of it. 

actors comprises a group of actors connected by rela- Replacements are done using an audit process, 

tionships. For example, a network of actors can be Transfer: given two actors A and B, a transfer from A 

based on the A-Kind-Of (AKO) relation. One network 45 t o B results in giving all attributes and relations from A 

of actors (NA) could comprise all actors that are A- ( 0 B while preserving the respective addresses (identifi- 

Kind-Of German, and another network (NB) could cations) of A and B. 

comprise all actors that are A-Kind-Of Frenchman. If Cloning: cloning an actor results in making a new 

an actor A is A-Kind-Of German, and an actor B is instance of the actor with all the attributes of the origi- 

A-Kind-Of Frenchman, then the merge of (NA) and 50 nal one at the current-time. A clone can physically 

(NB) can result in cither all Germans becoming French- share the attributes of the original (to save space) until 

men, or all Frenchmen becoming Germans, or alt Ger- a change is made to one of the attributes of either the 

mans and Frenchmen becoming Franco-Germans, a clone or the original resulting in physical separation of 

combination of the two. these attributes. By default all values are initially shared 

The merge operation provided for actors is dynamic, 35 between the original and the clone except for attributes 
it can be called by the user at run-time. Moreover, since of actors that are actors themselves. Assume, for exam- 
actors have the ability to memorize changes to their pie, that an actor in the system is a phone with two 
attributes and relations, it is possible to implement a attributes, a handset and a phone number. The handset 
mechanism to undo merging as any other operation on can also be an actor. If the handset is also an actor in this 
actors. Undoing a merge operation is called splitting. 60 example, cloning the phone results in the clone and the 

A split operator is made available to provide a de- original initially sharing the value of the phone number, 

composition mechanism and assist design evolution but not sharing the same handset. This is because the 

from a complex actor to communication mechanisms handset "attribute" of the clone is a new actor. Only 

between a set of simpler actors. This is particularly values are shared between the clone and the original, 

important since sending or processing communications 63 not actors. 

are atomic operations. Splitting provides a mechanism Cloning an actor may result in cloning a network of 

to decompose a communication into smaller atomic actors that are connected to each other by a relationship 

operations. (e.g. an actor and its components under the Part -Of 
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relation). A clone has a different address than its origi- actors. A Tape Program is said to be actor correct if it 

nal. Cloning is a mechanism to make inexpensive copies comprises all the actors necessary for its execution, 

(since data is reused until it is changed). The (optional) Similarly, a Tape Program is rule correct if it comprises 

visual representation of a clone is identical to the origi- all the rules of behavior necessary for its execution, and 

nal except for the addition of instance numbers in the 5 a Tape Program is sub-tape correct if it comprises all 

name of actors instantiated references to Tape Programs necessary for its execu- 

Rule of Behavior: in the VSM. a rule of behavior is an tion. A Tape Program lists all the actors and all the rules 

£mES„ of ™ fi^"^ ° f k Ct$) ' ' Wam maVhave an empty set of initial actors since 

combination of predicates on these knowledce-bases, a in * T. » • ^ . J . 4 . 

c-# rt fn n *-,„„vl f ; rt ^ u . _ *u * j 1 Script Rules or General Scripts can be used to create 

set or communication messages between the actors and *h ■ v i t 

a set of computations and assertions. A rule of behavior ™ininw actors. 

R on an actor set A can be described using the form: T *** Scenano: the of . a Tape Program 

produces one or more Tape Scenarios which are the 

R(A)J(P(A))» > M(A)= > g(Q(A,M(A)))) execution history of a given set of Script Rules from the 

15 original Tape Program corresponding to scenario varia- 

where A is a set of actors, P(A) is a set of predicates on *»°ns. 

the actors, f(P(A)) is a function (e.g. a boolean expres- Tape: a tape is composed of two reels, a future-reel or 

sion) of these predicates, M(A) is an optional set of Tape Program and a past-reel (comprising one or more 

communications between the actors, Q(A,M(A)) is a set executed tape scenarios), a tape counter, an optional set 

of computations and resulting assertions made to actors of initial actors, an optional description of multiple 

of the set A based on the actors knowledge and on views, required for its visualization, and additional in- 

in formation derived from the communication set M(A), formation used for reference and documentation. The 

and g is a composition function (e.g. a boolean expres- future-reel represents the set of available behaviors, the 

sion) used as a measure of completion of rule R(A). past-reel represents the history of execution of the tape. 

Under the boolean assumption, g(Q(A, M(A))) should " It contains instances of rules previously used and his- 

be true when the execution of R(A) completes success- tory of actors involved in these rules. The tape counter 

fU » y * »- j /- • • r indicates the simulation count (or time) for the number 

.5 definition of R ( A >» the «t A can defined of steps already executed in the tape (past-reel). When a 

C ?- P * Itl ^A C, . Cn J u ? cr ^ d): 1 A= ; a1 ' a2 an or im- ^ is fully rewound, its past-reel is empty, i.e., the 

plicitly. If A is defined implicitly. A can be described cxe cution history is lost and the future reel contains the 

SEX a A SCt A f 'SSvi "v 1 ? t0 l6 T f ? l Ct ° r ^ f0r tl f rulc ■* of a » rules that have been derived so far. 

R(A): A==Audit{Xl, X2, Xn) these lomcal rules Tape Class: the class of tapes defines the class of 

can portray characteristics {X , X2 . . . , Xn] reqmred computational entities ^ op £ ators ircd to 

lu£*lZl° P ,ayag,ven role Characteristics can be semi-automated (assisted) program manipulation 
pattern maichmg expressions composed of actor attn- " £ ^ K QT f|lm ^ 
butes and values. For example actor characteristics can XaM a + n JT.\*-\fi* A ^ J\„ * J 
include type checking, class dependency checking, con- I*^ r K t P t ^ ♦ a ♦ a 
nection ty£ checking (is therV a wire connection be- 9 J^^7j^^ ^ & f ****** 
tween and ' V?), or value matching (is there an 800 l ° 8Ct t her ""T' \ ? **** ° f 
phone number to this office?). An audition process (au- <° ^avior as well as integration and combina- 
dit) is used to identify candidate actors described by the Uon of scveral *P"*"> Dunn * rccord,n «» 
set of characteristics for rule R(A). A rule describing Upes arc a * omat "*"y stretched to record new corn- 
actors of A can request creation of new actors, reuse or mumcallons or ^ ore deUuI a specific communica- 
combination of existing actors. tlon " A ls 8,80 automatically stretched to provide 
OOScript: refers to a particular format and syntax « room t0 Insert more Scn P t Rules ' gyrated by the 
used to represent a single transaction between a sender G M S svstem or m "^Ponse to user input, between two 
actor and a receiver actor. An OOScript is a particular ? ones. The tape implementation supports record- 
textual representation of a single transaction between ing at va rious levels of detail and in multiple views 
two actors. Each OOScript can be used to describe one (cach la P e has »«hipl* tracks). In the VSM, recording 
rule of behavior involving one or two actors. However, 50 does not erase existing scripts from the tape, but inserts 
the OOScript syntax does not provide for the descrip- new ^"P 15 between existing ones. Deleting scripts is 
tion of actors. The OOScript representation belongs to done bv cutting or menu selection (command) to re- 
the class of formal representations for Rules of Behav- move a $crip\ Rule - 

ior defined above. In the GRAS implementation, for Tape Cutting: cutting a tape occurs at its current 

example, OOScript tuples are used to provide a simple 55 position (in simulated time) and produces two tapes 

textual format to interface between the internal rule which are valid tapes by themselves. To cut a tape, 

structure (maintained by the inference engine) and the select the Film Editor. These topes will both be stored 

user (or external application systems). on the tape shelf after cutting. The tape is copied before 

Role: the role of an actor is the set of all the rules of it is cut. Cutting the tape creates two half tapes that are 

behavior that apply to it in a given context. An actor's 60 automatically repaired by adding a future-reel to one 

behavior can be changed dynamically since, for an ac- side and a past-reel to the other, creating two new exe- 

tor, each rule of behavior requires interaction with cutable tapes. The viewer is prompted to name the two 

other actors. new tapes. 

Tanes in the VSM Tape bluing: g lui "g * a pe s joins * w <> or more tapes 

pes in tne 6J t0 g elner j nl0 one continuous tape. To glue a tape, select 

Tape Program: a Tape Program contains an initial the Film Editor. Tapes are copied before they are 

(and optional) set of actors and a set of Script Rules or glued, the past-reel of the first one and the past-reel of 

Genera] Scripts which define rules of behavior between the second ones may be unwound. The end of the first 
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one is then glued to the beginning of the other, the two 
spare reels vanish during this operation. 

A user may glue together more than two tapes. Glu- 
ing several tapes can lead to serial execution of the tapes 
viewed in sequential simulation mode and parallel exe- 5 
cution in concurrent simulation mode, even though the 
tapes interna] representations are identical. 

Tape Query; a tope query refers to a tape recorded 
with partial descriptions of actors and communications. 
Partial descriptions can be audit expressions and pattern 10 
matching expressions for preconditions, postconditions 
and messages. A communication between actors from a 
tape query is used to retrieve, by pattern matching on 
script structures, similar communications from a given 
set of Script Rules. 15 

Internal Tape Invocation: is the invocation of a tape 
(sub-tape) directly from the tape shelf while executing 
the current tape. The invocation is triggered by a post- 
condition to a Script Rule in the current tape. An in- 
stance of the tape is created that is executed in the cur- 20 
rent Soft Coder context. The actor system currently 
used may or may not be reused by the sub-tape at the 
discretion of the designer. If the sub-tape specifically 
refers to an actor used in the calling tape, this actor is 
reused. Recursive tape invocation is the special case of 25 
the current tape or one of its sub-tapes invoicing itself. 

Tape Compiler: is a processing mechanism on the set 
of Script Rules defining a tape to provide more efficient 
execution to the possible detriment of editing and undo- 
ing. The result is a compiled tape. A tape compiler can 30 
provide more efficient execution by removing the 
graphical representation of actors and the graphical 
side-effects of communications and connections be- 
tween actors in the tape. A tape compiler may also 
modify the set of Script Rules in the tape for optimiza- 35 
tion and produce a pre -computed lattice of Script Rules 
for fast execution. 

Visual Query: is a set of interactive visual operations 
designed to formulate queries and retrieve information 
from the tape shelf. The same mechanism is used to 40 
formulate a visual query that is used to record a stan- 
dard tape, except that a tape query is generated and then 
matched to portions of tapes from the tape shelf. The 
result of the query applied to the tape shelf is an ordered 
set of tapes with a list of pairs. Each pair comprises a 45 
number that is the confidence value of the candidate 
match and a pointer to the location in the Tape Program 
where the candidate match was found. As a result of a 
visual query, a user may inspect the graphical simula- 
tion of each tape around the location where the match 50 
was successful. This is useful for retrieving design infor- 
mation and building new designs from existing ones. 

Actors in the VSM 

In the VSM, actors represent a similar concept as in 55 
theater and movie production. Actors are available 
from a pool of individuals residing in the BackStage. 
Actors can be created (new) on demand or obtained 
from a pool of previously created actors. They live 
(exist), perform (play) and die (are destroyed). In addi- 60 
tion since actors are computer entities they can be cop- 
ied, reused, merged, split, and replaced. Actors can be 
loosely defined for certain scripts, in which case an 
audition process (audit) is conducted to select actors 
with appropriate characteristics from a pool. From the 65 
user perspective, actors must appear as very flexible 
agents to store and access knowledge and perform com- 
putations. 
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Actors can be members of zero, one or more tapes. A 
tape lists the address of all actors that play in the scenar- 
ios derived from simulating the tape. This list may vary 
in time. In the VSM, a tape is originally built from 
examples. Building behaviors by example implies that 
specific instances of actors are created and used during 
the recording of the tape. 

Script Structure 

The data-structure used to implement Rules of Be- 
havior in the GRAS system is of the form: Saddress^ - 
(Type,Sid, Group-Saddresses, Pre-Saddresses, Post- 
Saddresses, Sender, Sundo, Receiver, Rundo, Precondi- 
tions, Message and Arguments, Postconditions, Docu- 
mentation). The arguments of script are defined as fol- 
lows: 

"Saddress" is the address of the Script Structure in a 
given processor. When Script Structures are distributed 
on independent processors, an Saddress can have a 
prefix giving the address of the processor (e.g. Sad- 
dress: = ProcAddress:Saddress). 

"Type" is a legal combination of the Script types; 
Rule, General, Instance, Group, Wait, Undoable, Sent, 
Processed. The type is used by the inference engine to 
process the Script Structure according to the descrip- 
tion of the Script Type. The types Rule, General and 
Instance can be combined with type Group. The types 
Instance and Wait can be combined with type Undoa- 
ble. The type Instance can be combined with the type 
Sent or Processed. 

Sid: an identifier used for symbolic reference in other 
Script Structures and for symbolic presentation to the 
user. 

Group-Saddresses: used when a Script Structure is of 
type Group to refer to the set of Script Structures that 
are members of the group. 

Pre- and Post-Saddresses: are structures of Sad- 
dresses to other Script Structures. This is used to pro- 
vide support for the design of efficient execution mech- 
anisms that enhance the performance of GRAS on par- 
ticular architectures. Typically, Pre-Saddresses of a 
Script Structure S are addresses of Script Structures 
that may directly precede the execution of S, and Post- 
Saddresses indicate Script Structures that may directly 
follow the execution of S. This provides a lattice struc- 
ture for efficiently executing and reversing the execu- 
tion of large sets of Script Structures. 

Sender and Receiver: are expressions referring to the 
sender and receiver actors in this Script Structure. De- 
pending on the script Type the expression is interpreted 
differently. 

Sundo and Rundo: are expressions describing a set of 
computations required to undo all changes to the sender 
and receiver actors, respectively, caused by the execu- 
tion of the Script Structure. Sundo and Rundo are 
empty for Script Structures of type Rule, and General. 

Preconditions: a precondition expression is a combi- 
nation (e.g. a boolean expression) of functions, and logi- 
cal tests on the attributes of the script actors at the 
current simulation time. Preconditions based on sender 
and receiver actors are permitted to simplify the design; 
however the preferred style is to separate preconditions 
on the sender actors and preconditions on the receiver 
actor. To access information about a receiver, a request 
should first be sent to the receiver and the result from its 
reply should be used in the precondition of the next 
rule. On each processor where a set of actors is per- 
forming scripts, a clock is available where required, and 
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!l ™li^, , I?-^ ti ? , T e ^ iSt ^?' of Structure execution actor addresses. A Script Instance has non-empty 

is maintained. Under these assumptions, preconditions Sundo and Rundo fields after it has been executed 

^S^L^ d .? ,endencies ' ,h " * expres- These fields describe operations that must be completed 

«ns formed using tune operators and execution time of to reverse the effect of executing the Script Instance 
other Script Structures. Timing expressions may be 5 once. 

used to order the execution of Script Structures (based Script Group: a Script Structure which directly re- 

on their umque script-identifiers). In the GRAS imple- fers to a set orScript Structures. For example, a General 

mematoon. the simulated-time constraints are based on Script can be instantiated into a Script Group if the 

M^.. C ^ t H°* UOn ' . ... Audit process returns more than one actor couple (e.g. 

Message and Arguments: Message" is a symbolic io communication broadcasting). Script Instances are also 
name of an optional message passed between sender and automatically grouped by the inference engine (Sort- 
receiver actors. A message is used to communicate Coder) for parallel execulion. Groups can also be de- 
mformation between actors. When arguments are sped- fined to force the execution of Script Rules on the same 
tied they comprise an arbitrary set of data or computa- processor. An instantiated Script Group has non-empty 
tion expressions based on data from sender acton. 15 Sundo and Rundo fields. 

Postconditions: a postcondition expression describes Wait Script: a Script Structure generated by the Soft- 
changes made to an actor's attributes based on computa- Coder to delay execution during a simulated-time inter- 
Oons performed on initial attribute values, and in the val. This is necessary because there may not be any 
case of receiver actors, on data computed or transferred script that can be executed during a certain period of 
to the receiver via the message passed. It is preferable to 20 simulation time. For example, a message that issent may 
decompose the Postconditions into postcondition ex- take several simulated-time units before it is received 
pressions for the sender actor and postcondition expres- and can be processed. Or a message may be received but 
sions for receiver actors. cannot ^ p rocess ed until later. 

lamentation: a field used to comment on the func- Undoable Script: a Script Instance or a Wait Script 
tion or the Script Structure. The documentation can 25 which has been executed and has the necessary Sundo 
mclude symbolic references to the actors of the Script and Rundo expressions to be reverse executed (undone). 
Structure and I their attributes and data. The documents An Sundo or Rundo expression removes from the cor- 
tion may read differently depending on the data con- responding actors data-space all slots and values that 
ents. The documentation is minimally a text descrip- were changed after the simulation time when the Script 
tion. but graphics, video and audio may be used in par- 30 Instance was initially executed. The slots and values 
ticular implementations. that existed before the Script Instance executed are 

I lie actor attributes tested in preconditions or thereby restored, 
changed in postconditions can represent relationships 

between actors (relationships between sender and re- DESCRIPTION OF THE GRAS SYSTEM 

ceiver actors). In addition, entries performing input- 35 FIG. 1 is an architectural diagram of the GRAS sys- 
/output functions with the outside world (for example, tern. Video Studio Metaphor (VSM) Interface module 
asking the user a question) are accepted in precondi- 100 is a software module for providing a simple user 
tions, messages and postconditions but recommended interface and direct access to the entire system design 
solely in postconditions. All preconditions are tested in and simulation environment under a single unified meta- 
paraUe, all message attributes are communicated in 40 phor. The VSM lets the user record examples of system 
parallel and all postconditions are execuled in parallel. behavior into tape scenarios using visual programming 
Th.s enforces a parallel communication model for ac techniques, and combine and refine these examples into 
tors. When serial execution is desired, separate scripts tape programs while maintaining visual feedback about 
and serial Script Groups are used. the specified system behavior via graphical animated 

Types of Scripts 4S simulation execution. The VSM lets users capture, 

c ■ . d i c c . communicate, edit and combine designs via the use of 

Script Rule: a Script Structure of type Rule does not Video Connectors and various editors (Film Edit6r). 
nave instantiated sender and receiver actors, instead it The VSM Module also calls appropriate lower level 
refers to an actor using a symbolic name or an expres- GRAS modules to perform required tasks for a user of 
sion which evaluates to one actor address. This can be 50 the system. The next level of modules comprising a 
..l^^ tl ^ TO f J orMac ' or ?P«™tion returning, Management of Visual Object Networks (MoVon) 
S.TtT.JTl A ^ Rule has emp,y raodu,e n0 - a video recorder (SoftCoder 

J? * 'V s ™} ' n eXeCUted module m > ™ d • Connector (VQ module 130 

scrip . therefore, there is no "undo information" to are transparent to the user. The VSM Interface commu- 
maintain. S3 nicates with these modules over bidirectional messaae 

General Script: a Script Structure of type Genera] links (111. 121, and 131) 
uses Audit expressions to specify its actors. Sender and Management of Visual Object Networks (MOVON) 
Rece.ver constitute two Audit expression which pro- is an implementation of actors that supports vbuaS 
duce a set of couples of actor addresses (Sender Ad r tion of system components and networks of components 
a*"* 1 ? 1 ??- eneral SCnp ' has en,p,y 60 m mu,,i P lc mu,ti P Ie hierarchies and multiple 

«£.Ti ? J ■ c r levels ofdetail.TheMOVON module 110 calls upon an 

Script Instance: a Script Siructure of type Instance Actor Frame (AF) module 140 and a Prescript module 
results from the instantiation of a Script Rule or a Gen- 160 to perform its functions 

eral Script For a Scnpt Rule, when sender and receiver Software Coder (SoftCoder) module 120 is a virtual 
actors are identified by the.r addresses, a Script Instance 65 machine to record and simulate or execute actor trans- 
is created where Sender and Receiver are replaced by actions and communications. The SoftCoder module 
these addresses. For a General Script, a set of Script 120 provides a general mechanism to record (enter) 
Instances is created corresponding to each couple of play (execute) and undo (reverse execution) specifica- 
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tions supplied by simple or composite screen interne- frame base splitting (distribution) and frame base recon- 

lions. These interactions represent communications struction from distributed subsets via merging, multiple 

between actors with information transfer and computa- hierarchies and local class precedence lists, and message 

tion. The SoftCoder virtual machine processes a Tape broadcasting in multiple hierarchies. Where the mes- 

Program describing Rules of Behavior between actors, 3 sage broadcasted comprises a reference to a method, a 

instantiates actors and rules and produces a Tape See- function, a procedure, or a lambda expression in com- 

nario that is a complete trace of the system execution. piled or interpreted form that is called with at least one 

At each execution step in a Tape Frogram, a set of functional argument: the current frame in the hierarchy, 

computations is performed. Each step can be reversed A lambda expression is a stand-alone computer code 

by "undoing" it. 10 segment comprising all environment variables neces- 

A SoftCoder virtual machine also captures and simu- sary to its execution, assuming it is invoked with the 

lates actor communications, and state changes. During required arguments (e.g. the current frame), 

recording, the SoftCoder automatically encodes soft- In the ORAS system, the execution mechanism of a 

ware segments into general Rules of Behavior from the tope is based on the dynamic attributes of actors. Tape 

specific examples provided by the user through visual 15 editing operations have an cfTect on a combination of 

and menu interaction (recording of actor transactions). dynamic and static attributes of actors. Static editing 

Each Rule of Behavior may be interactively refined via flexibility is supported by the FOLIE module which is 

a group of special purpose software routines interacting part of AF module 140. The FOLIE module comprises 

with input from the user (Special Effects), and can eas- the following functions; (1) symbolic self description, 

ily be reused and changed when recording different 20 extensible, no type specificity; the symbolic self descrip- 

situations. tion of a frame set is order independent; all dependen- 

The sequential execution of each step replays the cies between frames are automatically maintained using 

example as it was input. The behavior described by the dual links, defining a frame set from its frame elements 

example may be interactively refined into a program for can be performed in any order; (2) multiple inheritance, 

describing behavior in all foreseeable situations. The 25 wherein a frame can inherit the union (set) of properties 

actors and Rules of Behavior can be edited at any time from all its parents; (3) multiple hierarchies of inheri- 

to change, to delete or add other information about the tance, wherein a frame can inherit properties from the 

state of the actor, the computation performed and the AKO hierarchy, or the PART-OF hierarchy, or any 

information exchanged during a communication. At the other relationship; (4) local class precedence list 

user's discretion, actor state and graphical representa- 30 (LCPL) comprising an ordered set of parents to a frame 

tion changes may be either permanent or temporary in a given hierarchy; multiple hierarchies provide for 

(reversible), The resulting rules actually form the Tape multiple LCPLs; (5) frame broadcasting, wherein an 

Program. operator can be broadcasted to all local class prece- 

The video Connectors (VC) module 130 provides a dence members in any given hierarchy; (6) frame net- 
mechanism to a user for program interaction and editing 35 work integration, wherein a frame is defined within a 
and connections to file systems and other systems exter- network of relationships with other frames; each frame 
nal to GRAS. The VC module 130 is a general transla- is self describing, i.e., a frame symbolically describes its 
tion and communication mechanism for the internal relational network with others, frame integration is 
tape representation used by the SoftCoder. The VC possible even when other frames are missing; (7) frame 
module is used to present tapes, actors and scripts in a 40 network merge, wherein two frame networks sharing 
textual format that is readable and editable by the user frame objects are automatically merged when linked 
or can be communicated to external systems. The VC Goaded) in the same system; (8) frame merging provides 
module provides a bidirectional connection mechanism four types of merge primitives: reuse, combine, over- 
bet ween GRAS and file systems and a bidirectional write and forget; (9) frame transfer provides for global 
connection between the GRAS and external systems. 45 substitution of a frame by another one while preserving 
Examples of connectors provided: OOScripts, Mes- the frame network consistency; if the replacement 
sages, Tapes, Actors (Objects), Scripts, Icons. When frame already exists, the transfer is performed via merg- 
connected via a VC to an external system, the external ing; this function provides support for actor replace- 
system can probe the GRAS system as well as remotely ment and actor merging. 

control the execution of GRAS. 50 A windows and graphics system (WG) module (170) 

Prescript is a graphical programming language, that (similar to commercially available X Windows Sys- 

is part of the GRAS system, for display and animation tern TM , Sun View TM , Symbolics GENERA® win- 

of actors and communications. The PreScript module dows) provides visual capabilities for GRAS. Common 

160 supports the visual representation of actors. Visual Lisp (CL) (ISO) is an implementation of the Common 

objects are associated with frame representations to 55 Lisp language according to the specification of the 

define actors (actor=visual object + frame + behavior). ANSI X3J13 committee (American National Standard 

A visual object is displayed on a computer terminal. It for Common Lisp under preparation). For GRAS, a 

can be merged with other visual objects and is a mem- subset of CL is used to reduce the size of the executable, 

ber of a tape defining a scenario (or set of scenarios) as The CL subset comprises only the necessary LISP func- 

well as a member of a tape frame. The PreScript module 60 tions to execute GRAS and is generated by traversing 

160 uses windowing and graphics capabilities 170 pro- the entire GRAS code and collecting all functions refer* 

vided by the OS 175. enced in the code. Other computer languages may be 

The Actor Frames (AF) module 140 is a knowledge substituted for CL as long as they provide analogous 

representation and storage mechanism that supports capabilities as defined by the ANSI specifications, 

time history of frames and actors knowledge. AF is 65 The Operating System (OS) 175 is a computer operat- 

bascd on the Frame Object Language and Implementa- ing system and an (optional) integrated environment 

tion Environment (FOLIE), a frame representation (e.g. UNIX ®, Symbolics GENERA ®). UNIX is a 

language that is part of the GRAS system and supports registered trademark of AT&T. GENERA is a regis- 
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tered trademark of Symbolics Inc. The OS controls and ally reclamation) Of Prescript objects via CL. AF can 

maintains the execution of the following components: request allocation (optionally reclamation) of frames, 

WO (170), CL (180), FS (185) and NW (186). scripts and tapes structures via CL. CL can request 

File System (FS) (185) is a component implementing allocation and reclamation of computer objects from 

the access mechanism for static data storage and re- 5 HW via OS and FS. 

trieval. It is based upon the UNIX file system. To further illustrate the connections between MO- 

Hardware(HW) (176) is a computer machinery com- VON, SoftCoder, VC, and other components of the 

prising one or more processors to manipulate data (sym- architecture, the language of the VSM can be used, 

bols, objects, databases) and to perform logical opera- When a tape program is rented from a video store (user 

tions and arithmetic computations, and one or more 10 request via VSM), VC opens a connection to FS or NW 

storage mechanisms and devices used to store and re- via CL and SoftCoder records input from the open 

trieve data (the storage is static and dynamic, with se- connection into a tape program that is placed on a tape- 

quential and/or random access). The hardware require- shelf (VSM). When a tape is loaded into the SoftCoder 

ment is to provide sufficient data storage and compute- (VSM command), SoftCoder request actors and display 

tion power to support the execution of all the GRAS IS views from MOVON, then SoftCoder invokes the ap- 

components defined here. Computer hardware cur- propriate execution algorithm. As SoftCoder executes 

rently available that were found suitable for the imple- scripts from the tape program, changes are ordered to 

mentation and delivery of a GRAS include: AT&T actors that are 1) controlled in time history by AF and 

6386 WGS, other UNIX computer mainframes with 2) may affect the visual representation of actors (e.g. 

AT&T 730 graphics terminal or X windows terminals, 20 animation) via MOVON-PreScript-WG. When the user 

Sun Microsystems SUN-3 and SUN-4 series, Intel 80386 pauses the execution to make changes or tries execution 

based personal computers, Symbolics 3600(g) and XL alternatives, changes are translated into script changes 

series, Xerox 1100 series, Texas Instruments Ex- and actor changes and propagated to MOVON and AF 

plorers®, and Digital Equipment Corporation DEC where they are temporarily or permanently installed. 

2000 and 3000 series. 25 Changes to actors and scripts are immediately visible as 

Network (NW) (186) (optional) comprises the hard- the SoftCoder executes the changes and propagates 

ware and software components available-with or ad- them via MOVON. 

ded-to the HW component to provide data communica- In the Video Studio Metaphor, example scenarios are 

tion between a set of VSM-based systems. Suitable net- interactively recorded into tapes. Example Scenarios 

work technologies currently available include: phone 30 are used to specify a thread of behavior for an existing 

lines with modems, Ethernet TM AT&T STARLAN, system or a system to be designed. Tape Scenarios are 

broadband packet networks. The NW component is interactively refined to incorporate new aspects of the 

only required to communicate VSC data electronically system behavior for new conditions and evolve into a 

(e.g. remotely accessing a tape program). Tape Program for all allowable conditions. After suffi- 

As shown in FIG. 1, the VSM module 100 has bidi- 35 cient refinement, a Tape Program provides a complete 

rectional connections to MOVON, SoftCoder and VC. simulation of the system represented or being designed. 

The direct connection (from VSM) represent user con- A Tape (Scenario or Program) contains a set of actors 

trol and access to: 1) the visual representation of actors and a set of rules describing behaviors and communica- 

and actor operations (MO VON),2) the visual recording, tions between actors. Actors are processing agents in- 

refinement and simulation of scripts and tape programs 40 volved in communication and computation activities 

(SoftCoder), and 3) external tape programs as well as that are driven by the execution of rules. An Actor 

the editing of tape programs in textual form (VC). Not provides an independent knowledge base used for the 

represented on the figure is a (optional run-time) bidi- execution of rules. Rules incorporate preconditions 

rectional connection existing between VC and external relating to facts in actor knowledge bases, communica- 

systems. The connections back to VSM (from MO- 45 tions between actors, and postconditions comprising 

VON, SoftCoder or VC) represent visual and textual computations and assertions to actor knowledge bases, 
feedbacks to the user interface display resulting in 

changes to one or more visual representations on the Actor Frame Module 
display screen. This feedback-loop is actually imple- The frame architecture allows users to integrate two 
mented via the common path through MOVON-Pre- 50 independent tapes by "loading" and "gluing.** Two 
Script-WG, all graphical changes are implemented as tapes sharing actors and rules can be integrated by load- 
changes to the visual representation of actors. VSM is ing them into one environment and applying tape gluing 
also connected through WG to the pointing device and and editing. Two tapes sharing roles and functions but 
the keyboard device controlled by the user. The VSM conflicting actor identifications can be merged by per- 
module receives direct input from the user who is not 55 forming actor translation (selecting actor replacements) 
represented on the figure. Equivalent input can be re- and the above step. Several users building piece-parts of 
ceived from an external system via the VC remote con- the same feature specification find unique computer 
trot feature. SoftCoder and VC transmit scripts, tape assistance for integration in such environment, 
programs and tape scenarios as well as SoftCoder con- The flexibility of the tape editing and merge features 
trol commands (e.g. load tape, remove tape, change 60 results from the integration of three components: the 
level of detail, change view). MOVON and SoftCoder frame representation language (FOLIE), the Manage- 
transmit actors and actor contents. MOVON can re- ment Of Visual Object Networks (MOVON) and the 
quest actor visual objects from PrcScript and actor underlying script language (e.g. OOScripi) used to de- 
frames from AF. SoftCoder can request frames and fine rule-based behavior of actors. Frame merging sup- 
frame instances, and tapes and scripts structures from 65 ports the merge of tapes and/or actor slots, values and 
AF. VC can request connections to FS and external relations (e.g. inheritance, membership relations). If a 
systems via CL and FS or NW. PresScript can request set of frames and their relationships is represented using 
display changes via WG and request allocation (option- a graph where the nodes represent the frames and the 
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arcs the relations, then merging two such sets of frames 
is equivalent to composing the graphs by merging nodes 
from each graphs and adding or removing (depending 
on the type of merge) arcs between nodes of the com- 
bined graph. An actor replacement operation, which 5 
can be seen as an extension of **becomes" in object-ori- 
ented languages, can be used to substitute an actor by a 
new one or merge the two actors if the destination of 
the replacement is an existing actor. Visual object 
merge supports integration of system components i.e., 10 
merging states defined as slots and values, and graphics 
attributes. Rule based tape program execution supports 
integration of actor behaviors from various tapes by 
performing rule-sets union. Combining programs by a 
set union of functions, objects or instructions in Stan- 15 
dard programming language does not usually produce 
any useful or meaningful result because the execution of 
each program instruction is conditioned by external 
implicit control flow defined by other surrounding pro- 
gram instructions. However, combining tape programs 20 
by set union of Script Rules and General Scripts and 
related actors can yield to the addition of functionalities 
from the tapes being combined with at least two advan- 
tages. First, each tape program "instruction" is a Script 
Rule or a General Script comprising actors or actor 25 
descriptions, execution conditions and resulting compu- 
tations and communication (message) and is therefore a 
stand-alone program instruction. Second, if two Script 
Rules from different tape programs being combined are 
conflicting, the conflict is of a well defined type: 1) the 30 
rules may be semantical! y contradictory, 2) there may 
be situations where both rules will attempt to update the 
same actor slot at the same time, 3) or one or more of 
the rules may be unreachable. The first two conflict 
cases will appear visually during the animation and 35 
simulation of the combined tape program execution, the 
second and third conflict case can also be detected using 
static analysis of the combined rule set. 

In GRAS, the underlying knowledge representation 
combining FOLIE, MOVON, and the internal Script 40 
Structure (e.g. OOScript) provides unique flexibility of 
use that is internally based on the merge operations 
described above (frame graph merge and behavior inte- 
gration by rule-sets union). 

The basic knowledge representation supporting all 45 
data storage and retrieval for the VSM is provided by 
the AF component of GRAS, AF provides a time his- 
tory mechanism, required for the reversible execution 
of communication scripts between actors, that is built 
on top of the underlying frame representation language, 50 
FOLIE. AF provides the necessary time history mecha- 
nism for actors (formalized earlier) by saving local snap- 
shots of the actor's frame each time a communication to 
or from that actor changes some attribute or relation of 
the frame. Besides this time history, all features of AF 55 
required for the implementation of GRAS are direct 
features of FOLIE. 

The execution mechanism of a tape in the VSM is 
based on storing and restoring dynamic attributes of 
actors. The tape editing operations described earlier 60 
have effects on a combination of dynamic and static 
attributes of actors. The implementation of changes and 
editing is directly supported by the underlying frame 
representation language, FOLIE. The implementation 
of dynamic changes is provided by a combination of 65 
FOLIE properties and the history mechanism that can 
store and restore snap-shots of frame attributes related 
to an actor. The important features of the FOLIE frame 
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language that support the required operations on static 
and dynamic attributes of actors include: 

Symbolic self description: a frame can "print itself 
using a symbolic description format that is independent 
from the computer environment where the frame is 
defined. The self description format is extensible: when 
the frame changes the same format is used in extended 
or shortened form to incorporate the changes. There is 
no type specificity in the format that could be computer 
dependent. The symbolic self description of a frame set 
is order independent. Given a set of frames {fl , f2, . . . 
, fn}, it is possible to store the self description of this set 
of frames in any order and restore them in different 
order in another instance of a GRAS system to create 
an equivalent frame set. 

Dual links: all relationships between frames are auto- 
matically maintained using dual links, restoring one half 
of the dual link is equivalent to restoring the whole dual 
link. This property supports the order independence of 
self description in frame sets. 

Frame networks: a frame can be interpreted as a 
network of relationships with other frames. Each frame 
symbolically describes its relational network with oth- 
ers, frame integration is possible when other frames are 
missing. It is therefore permissible to store and restore 
an incomplete network of frames: that is a set of frames, 

F={fl, (2, . . . , fn} where fi, a member of F refers to 
fj which is not a member of F. 

Multiple hierarchies of inheritance; a frame can in- 
herit the union (set) of attributes and relations from all 
its parents in a given frame hierarchy. While multiple 
inheritance is commonly available with other frame 
languages and object-oriented languages, multiple in- 
heritance according to multiple hierarchies is a novel 
feature of FOLIE. A frame can inherit properties from 
the AKO hierarchy, or the PART-OF hierarchy, or 
any other relationship defined in GRAS. Each dual 
relationship defines its own frame hierarchy. 

Local class precedence list (LCPL): constructs an 
ordered set of parents to a frame in a given hierarchy. 
Multiple hierarchies provide for multiple LCPLs. 

Frame broadcasting: an operator, or a function can be 
broadcasted, being applied to all members of a LCPL in 
a given hierarchy. 

Frame merge: is a mechanism to combine and reuse 
information stored in frames. Frames can be merged via 
four basic merge primitives: reuse, combine, overwrite 
and forget. When merging two frames f 1 and f2 to con- 
struct a frame f(l+2): 

1) . reuse: f(l + 2) inherits from fl and fl with prece- 
dence on fl. The attributes and relations of fl remain 
and non overlapping attributes and relations from fl are 
added. 

2) . combine: f(l+2) inherits from fl and f2 with 
equivalence. The attributes and relations from fl and f2 
are stored as union sets into f(l + 2). 

3) . overwrite: ft 1+2) inherits from fl and f2 with 
precedence on f2. This is identical to merge with reuse 
between O. and fl. 

4) . forget: f(l+2)«=f2. The merged frame is replaced 
by the original frame f2. 

Frame transfer: provides for global substitution of a 
frame by another one while preserving the frame net- 
work consistency, thus maintaining existing dual links. 
If the replacement frame already exists, the transfer is 
performed via merging. This feature directly supports 
actor replacement, cloning and merging described ear- 
lier. 
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Frame network merge: two frame networks sharing Let (FUN1 ARGI ARG2) be a function call expression 

common frames are automatically merged when re- representing the invocation of a function FUN1 on 

stored in the same VSM based system, arguments ARGI and ARG2. 

The flexibility of tape editing and feature merge in The arguments can themselves be function call expres- 

GRAS results from the interaction between the three 5 sions, providing a representation for embedded function 

main components of the architecture: the frame repre- calls. 

sentation language integrating time history (AF and Let :: =be the "bind" symbol so that VAR::=(FUN1 

FOLIE), the Management Of Visual Object Networks ARGI ARG2) indicates that VAR is bound to the 

(MOVON) component and underlying properties of the resu it of the function call. 

Script Structure used to represent rule-based behavior 10 Lc t «-be the "equality by definition" symbol. 

of actors (SoftCoder). The following examples illustrate Ut. >be the "value returned" symbol. For example: if 

the integration of these software components; VI:: —123 then VI- > 123. 

1). Frame merging supports static or dynamic merge ^ p'^ ^ Framc object identified by a unique Lisp 

of tapes, actors and relations (e.g. inheritance, member- object (e g a symbol) 

ship, subcomponents). This type of merge is identical 15 ^ FB ^ my Frarne BasC( where FB is a structurc 

to a graph merge where each graph is a tape linked to comprising a set of Frame Objects. 

Script Structure describing actors behavior, linked to Ut MFB ^ti pie Frame Base) be the general type 

J^ ft i° a ^ m 1 P° ncnt * ctors > _ . (class) of frame base objects defined in FOLIE. 
Jhn^Z u rc P laccmem °P crat,on can suh ? 1 '- w Let NX be a sequence of n slots NX-(XI X2 . . . Xn), 

20 to X=X» be\ slot in NX, let BNXi be the subsc- 

Z £ 1~ of NX Xi ™* ANXi be the subse- 

ing, merging and support user experimentation with 2 ~r MV v . /AWV . Jy 01 . TV . . 

new design componentT < ucncc °f NX aftCT Xl <* N * a " d/or ™ X) * 

3) . Visual object merge supports the integration of SlSS? TT 0) " ?\ NX=BNX.| 
system components and their graphical representations 25 < X >I ANX ' where [ represents the concatenate of 
and gives direct visual feedback to the user when re- sequences. 

placement, cloning or merging takes place. m^^S™" , C I eat '° n: • , , . » . 

4) . Rule based communications between actors as MFB (&rest F-set)-Create a simple frame base that is a 
provided by the Script Structure and their execution by collection of F frame objects. 

the SoftCoder supports features and components inte- 30 J^^Pjf; 

gration from multiple tape programs by performing (MFB Fi F2 F3)->(F1 . . F2 . . . F3 . . . ) indicates that 

rule-sets union. tnc i™ 1 * 1 * bast contains Fl, F2 and F3. 

In GRAS. the underlying knowledge representation 3 >* Multiple Frame Base Creation: 

combining AF, MOVON, and the SoftCoder provides MAKE-MFB (Aoptional FB F NX-set (MERGE- 

novel flexibility of use and experimentation with system 35 TYPE: COMBINE))-Frame and frame base creation 

design. It is possible to simulate, combine and analyze and Where all arguments are optionals, where 

existing and new designs in a very accessible and user NX-set is a set (sequence of) NX, where MERGE- 

friendly way. The flexibility of use is largely a result of is OM of CREUSE: COMBINE: OVER- 

the unique and semi-automated assistance for such oper- WRITE: FORGET) as defined earlier and where the 

ations as merge and integration of rules of behavior 40 default value of MERGE-TYPE is: COMBINE, 

provided by the interaction of the three basic compo- Examples: 

ncnts of the GRAS architecture: AF, MOVON and FB;: = (MAKE-MFB) creates an empty frame base. 

SoftCoder. (MAKE-MFB FB F) adds the empty frame F to the 

frame base FB. 

FOLIE 45 (MAKE-MFB FB F (NX1 . . . NXp)) adds the frame F 

The following is a description of the Frame Object comprising the set of sequences of slots (NX1 . . . 

Language and Implementation Environment (FOLIE). N*P) to FB. 

For purposes of clarity, a Lisp-like syntax adapted from If F is already a member of FB then (NX1 . . . NXp) is 

Common Lisp (G. L. Steele Jr., Common Lisp the Lan- merged by combination with the existing frame F. 

guage. Digital Press, 1984) is used herein to define FO- 50 (MAKE-MFB FB F (NX'l . . . NX'p): FORGET) 

LIE, and several examples are included. The FOLIE replaces the existing definition of frame F by a new 

operators defined herein are named with naming con* one. 

ventions similar to Common Lisp and the Common 4). Accessors and Assertors: 
Lisp Object System Specification (CLOS) (E>. Bobrow, GETMFB (Aoptional FB F &rest NX)-accesses the NX 
"CLOS," Xerox document 87-002, 1987 and S. E. 55 slot description of frame F in FB. 
Keene, Object-Oriented Programming in Common Lisp, GETMFB (&optional FB F &rest NX)::=VALUE- 
A Programmer's Guide to CLOS, Addison Wesley, New add VALUE at the NX location for frame F. Adding 
York, 1989). The definition of Local Class Precedence the empty sequence ( ) as value is equivalent to re- 
List in FOLIE is inspired from the definition of Class moving the current value frame at location NX in F. 
Precedence List in CLOS. 60 Adding the true frame statement T as value of 

1). Notations and Definitions: GETMFB is equivalent to asserting NX in F. It 

Let FUN1 (ARGI ARG2) be a declaration of FUN1 to should be noted that if VALUE is not ( ), it is added 

be a function of two arguments, ARGI and ARG2. to F by creating a local frame containing the given 

Let "AoptionaT declare optional arguments and value (a value frame) and that the "addition** of a 

"Arest" declare the collection of all remaining argu- 65 value is done by merging. Therefore, in FOLIE, a 

ments to a function. frame base is a multiple frame base in the sense that 

Let "Aoptional (DEPTH 0)*' be a declaration for an each sub-component of it is a frame base, 

optional argument named DEPTH with default value 0. If should be noted that: 



03/13/2004, EAST Version: 1.4.1 



23 



5,247,651 



15 



20 



25 



{(GETMFB FB F XI . . . Xn)::«T} = (MAKE-MFB 

FBF(Xl...Xn)) 

Examples: 
(GETMFB FB F XI X2)::=VALUE12 
then; (GETMFB FB F XI X2>>(VALUE12 . . . ) this 5 

indicates that at slot location (XI X2) in frame F of 

FB a value frame exists that now contains the value 

VALUE 12 and possibly other previous values. 
(GETMFB FB F XI X2 VALUE12»(T) indicates 

that at slot location (XI X2 VALUE 12) there exists a 10 

true value frame (a non empty frame). 
(GETMFB FB F X1»(X2 (VALUE 12 ...).) 

indicates that at slot location (XI) in frame F there 

exists a value frame that contains at location (X2) a 

value frame containing VALUE12. 
(GETMFB FB F X 1 X2)=* (G ETMFB (GETMFB FB 

FX1)X2) 

(GETMFB FB F XI X2)= (GETMFB (GETMFB 

(GETMFB FB) F) XI) X2) 
(GETMFB FB F XI X2)::=NEWVALUE 
(GETMFB FB F XI X2)->(NEW VALUE . . . VA- 
LUED . . . ) indicates that both values are now mem- 
bers of the value frame at location (X 1 X2) in F. 
(GETMFB FB F XI X2 VALUE12):; = ( ) 
(GETMFB FB F XI X2)-> (NEW VALUE . . . ) indi- 
cates that VALUE12 is not a member of the value 
frame at location (XI X2) in F. 
(GETMFB FB F XI X2 VALUE 12»( ) 

5) . Multiple Assertors: 30 
When the frame or one of the slot argument of 

GETMFB is itself a frame base, and GETMFB is in- 
voked for an assertion, then the assertion is multiplied 
and distributed to all members of the frame base argu- 
ment. 35 
Examples: 

Let X:: = (MFB A B C)->(A . . . B . . . C . . . ) with 

NX=BNX|(X)|ANX 
Then: 

{(GETMFB FB F NX):: =Y}= {(GETMFB FB 40 
F|BNX|(A)|ANX| and 

(GETMFB FB F|BNX|(B)| ANX| and 

(GETMFB FB F j BNX | (C) | ANX | )} 

(GETMFB FB F |NX|::=( ) removes all three asser- 
tions. 45 

In particular: 

(GETMFB FB FB |NX):: = T asserts NX to all frame 

element of the frame base FB. 
(GETMFB FB FB)= (GETMFB FB) and 
(GETMFB FB FB)::=( ) removes all facts from all 50 

elements of FB 

6) . Relationship Accessors and Assertors: 

A sequence of slot NX can be used to specify any 
symbolic relation between frame objects. In particular, 
dual relationships can be defined in FOLIE using multi- 55 
pie slot sequences using the following syntax: 

Let:>be the "forward" link symbol 

Let:<be the "backward" link symbol then (GETMFB 
FB A:>B)::=T asserts a dual relationship between 
frame A and frame B in the frame base FB. All opera- 60 
tors on frame objects defined in FOLIE maintain 
duality of relationships by enforcing the equivalence 
relation defined below. 
Let FB be the current frame base. 
Let (GETMFB FB NX)::=T be represented lo the 65 
short-form [NXJ^Xl X2 . . . Xn to indicate that the 
assertion NX is true in the frame base FB. 
Let < = >be the equivalence symbol. 
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Let (MFB A B C) a frame base comprising A, B and C 
as elements be represented by the short form (ABC). 
Then the following assertions about relationships in 
FOLIE are true: 

a) direct relation equivalence: 
A:>B< = >B:<A 

b) many-to-one-relation distributive y: 
(AB):>C< = >{A:>Cand B:>C} 

c) sink-relation dtstributivity: 

FB: > OMEGA < = > for all F in FB {F:> OMEGA} 

d) one-to-many-relation distrtbutivtty: 
A:>(B C)< = >{A:>B and A:>C} 

e) totology-relation distributivity: 

ALPHA: > FB < = > for all Fin FB {ALPHA:>F} 
0 N-ary relation equivalence: 
A XI X2 . . . Xn:>Z< = >Z XI X2 . . . Xn;<A 
and the assertions a) through e) above are true for N-ary 

relations as well. 

Example: 

(A B C) CONNECT SATELLITES VEGA 

< = >{A CONNECT SATELLITE : > VEG A 
and B CONNECT SATELLITE: > VEGA 
and C CONNECT SATELLITE: > VEGA} 

< « >{VEGA CONNECT SATELLITE: < A} 
and VEGA CONNECT SATELLITE: <B 
and VEGA CONNECT SATELLITE: <C} 

7) . Set Operators: 

Let FB be the current frame base used as a "root" to 
assert all dual relationships during the following op- 
erations. 

MFB-MERGE (TYPE FBI fircst FB-set)-Merge a set 
of frame bases FB-set into FBI (changing FBI) ac- 
cording to TYPE a member of (:REUSE:COM- 
BINE:OVERWRITE:FORGET). 

MFB-INTERSECTION (FBI Arest FB-set>Change 
FBI to become the intersection of itself (its asser- 
tions) with (all assertions from) a set of frame bases. 

MFB-DIFF (FBI &rest FB-set>Remove from FBI all 
assertions from a set of frame bases. 

MFB-TRANSFER (FBI FB2)= MFB-MERGE 
(:REUSE FB2 FB1)-Use of merge equivalent to add- 
ing all assertions from FBI that have no similar in 
FB2 into FB2. 

MFB-UNION (FBI &rest FB-set) = MFB-MERGE 
(:COMBINE FBI &rest FB-set>Use of merge equiv- 
alent to set union of all assertions from the set of 
frame bases. 

MFB-REPL ACE(FB 1 FB2)= MFB-MERGE (:FOR- 

GET FB2 FB 1)-Use of merge equivalent to replacing 

FB2 by FBI in the frame base. 
MFB-XOR (FBI fcrest FB-set)-Change FBI to become 

the set of assertion that are pair-wise not true for both 

FBI and each frame base in FB-set. 

8) . Predicates: 

MFB-INCLUDE-P (&rest FB-set)-Is true if FB-set is 
an ordered set for the inclusion relation. For example 
(MFB-INCLUDE-P FBI FB2)->T means that FBI 
is equivalent to a sub- frame base of FB2: all assertions 
true in FBI are also true in FB2. 

MFB-MINIMAL-P (FB)-Is true if no assertions exist 
that are true about FB. For example ^MFB-MINI- 
MAL-P (MAKE-MFB))- > T. 

MFB-EQUAL (FBI FB2 ^optional DEPTH)-Is true if 
both (MFB-INCLUDE-P FBI FB2) and (MFB- 
INCLUDE-P FB2 FBI) are true. 
Note: the optional argument DEPTH is provided 

here and below for efficiency of certain operations, A 

default DEPTH of 0 indicates that the entire frame base 
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is explored. A default DEPTH of 0 indicates that the frame object F and all its precedents in the hierarchy 

first level of the frame base is explored. When DEPTH defined by NX in the frame base FB. 

is a number, it indicates the maximum size of the NX MFB- BROADCAST-COLLECT (FCN FB F NX 

slot sequences explored minus 1. ^optional DEPTH)-Similar to M FB-BRO A DC AST 

9) , Utilities: 3 ^ut collect the results of applying FCN to all prece- 
MFB.OOPY (FB &optional DEPTH).Makea copyof dents of F in the hierarchy. 

MFB-CLOSE (FB Arest FB-set)-Close all dual links Prescript 

ift FB K aS ref "™ C for J?? h r dual . ,ink ci0 »f?) for Visual programming of systems behavior and interac- 
^oS^ 10 tive/dynam^/flexible Siting in an interactive actor 

mf^pr i ntv*51 ttri^ a of\t^«at^TP p am^ ciippto^ and ™ le environment like GRAS is made possi- 
^fa ^ * * ■ .^nition of visual ^ An actor 

SUBFB. SUBFB can be a subset of FB or the entire f «« * trttCtu f c 15 augmented with a visual 

frame base FB. If STREAM is specified, it is used to I5 object to implement visual representations of actors in 
print SUBFB to the corresponding STREAM de- GRAS, mat is: 

vj ce Actor=D(A,t)=Base-Frame+{V.sual Object} + - 

MFB-READ (FB &optional STREAM DEPTH>Read {Behavior} and this actor is fully specified by its 
a symbolic representation of a set of frame bases from data-space description at time t, D<A, t). 
STREAM and merge the resulting frame bases into 20 However, the data-space description can be broken-up 
FB. mt0 8 visual object component, a basic frame descrip- 

10) . Mappers: tion and set of behavior specifiers from which the inner- 
MAP-MFB (FCN FB ^optional (DEPTH 0))-Apply 'ted set of possible behaviors at the current time (possi- 

the function definition FCN to all slots and values of bly empty) can be derived. 

FB up to DEPTH. 23 A visual object is self displaying and self describing, 

MAP-MFB-SLOT (FCN FB Aoptional (DEPTH 0))- can be merged with another visual object and can have 
Apply the function definition FCN to all slots of FB a variety of visual representations (e.g. icon, text, but* 
upto DEPTH. ton, geometrical shape, combination of graphical primi- 

MAP-MFB- VALUE (FCN FB icoptional (DEPTH tives). Moreover, a visual object associated with an 
0))- Apply the function definition FCN to all values of ^ actor can be a direct member of a tape. The frame corre- 
FB upto DEPTH. spending to the visual object is also linked to the tape 

11) . Local Class Precedence Lists (LCPL): frame. Therefore, an actor may have two links with 
The definition used for LCPL is inspired from the each tape instance it is used in, a link between the tape 

CLOS specification (Common Lisp Object Speciflca- and its visual object and a bi-directional link between its 
tion). Wherein CLOS, CPLs are defined for a single frame description and the frame description associated 
inheritance hierarchy (as provided with Object Ori- ^th the tape. 

ented Languages), LCPL is defined in FOLIE for any Underlying the visual objects representation is the 
hierarchy specified by an N-ary relation (defined by Prescript graphics language. Prescript uses a prefix 
riri * « notation, and a Lisp-like syntax as well as a Prescript 

MFB-LCPL (FB F NX Aoptional DEPTH)-Return an interpreter, a compiler and a debugger. Prescript is a 
ordered set of frame objects that constitute the class direct implementation of vector space algebra in two, 
precedence hierarchy of F in FB local to the hierar- ^tee or more dimensions extended to include the defi- 
chy relation specified by NX. If a number, DEPTH is njtion of a jmi device ( m0USCt cursor) and 
the number of successive NX relations explored. mechanisms to capture user input and provide output 

example: mechanisms 
Let FB be such that the following assertions (in short- 45 The p reS ^ ript includes d€ f lni , ions 

orm; are rue. f Qf vectors ^ normSf distances, vector operations (scalar 

ABCD product, addition, subtraction, vector product), orthog- 

onality, parallelism, points, lines, planes, hyperplanes, 
abcd I SO projections, perspectives, geometric primitive objects 

Cine segments, line paths, conies, polygones, parallel- 
dbce epipeds, cylinders, surface models), spatial location 

primitives (inside, outside, intersection, union, member- 
EI 6hip relations, hidden surfaces), linear and affine trans- 

E1BCZ 55 forms, similitudes (rotations, translations, scaling, point 

symmetries and plane symmetries). The Prescript 
then the local class precedence list for A in FB with «»phkd language also includes definitions of display 
relation (B C) is- devices, multiple viewpoints, textures, colors, character 

styles (fonts), input/output devices for text and coord i- 
(MFB-LCPL FB a (B C))->(A DDI E El Z) 60 nates, images (arrays of graphical elements), tiles, 

graphical periodicity and recursion. 
When looking for an inherited attribute of A for relation When an error occurs during the execution of a Pre- 
(B C) one looks successively in (A D Dl E El 2) for Script command, an error message is returned, and 
this attribute. The search for an inherited attribute is printed in an Explanation View, and the execution of 
done using MFB-BROADCAST defined below. 65 the current Prescript expression is aborted, however 

12) . Function Broadcasting: this does not arrest Prescript execution. Errors in draw- 
MFB-BROADCAST (FCN FB F NX Aoptional ing are never fatal in the sense that an error in display- 

DEPTH>Apply the function definition FC to the ing a given Prescript object does not prevent the fol- 
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lowing Prescript object from being displayed; however 
the second display result may be incorrect if it depends 
on the first one. 

A Prescript object is a well formed PreScript expres- 
sion comprising Prescript operators and arguments 
including typed arguments (e.g. numerical) and sym- 
bolic argument assumed to be bound in a hypothetical 
evaluation environment. A PreScript object can be a 
combination of PreScript primitives. A visual object is 
defined by combining four PreScript elements compris- 
ing: 

P=(d, c, i, s), wherein d="drawing'\ e="exterior" f 
i= "interior", and s= "sensor", and four sensor meth- 
ods (user-interaction behaviors): S=(in, ex, be, ac), 
wherein in = "sensor entry method", ex = "sensor exit 
method", bc="before-click method", and ac= "aft- 
er-click method". 

The Prescript elements are defined as follows: Draw- 
ing (d) is a PreScript object describing how to draw the 
visual object (independently from the display device) 20 
and an optional transformation function to provide 
animation from the initial drawing. Exterior (e) or mask 
is a PreScript object with a well defined interior used to 
delimit the visual object representation in a given view. 
Interior (i) or extent is a PreScript object with a well 25 
defined interior used to delimit the virtual interior of the 
visual object. Sensor (s) is a PreScript object with a well 
defined interior used to delimit an area sensitive to the 
positioning of a pointing device. 

The following is an example of a PreScript object as 30 
illustrated by the user actor 430 in FIG. 4: 



The Sensor methods are defined as follows: A sensor 
entry method (in) is a method invoked when the point- 
ing device enters the sensor area of the visual object. A 
default method is when the mouse enters a sensor area, 
the sensor region is highlighted. A sensor exit method 
(ex) is a method invoked when the pointing device exits 
the sensor area of the visual object. A default method is 
when the mouse leaves a sensor area, the sensor region 
is not highlighted. A before-click method (be) is a 
method invoked when the pointing device is used to 
make a selection in the sensor area (e.g. when the mouse 
is clicked). Several default methods are available in- 
cluding coloring the sensor area or redrawing it, pro- 
viding pointer-related motion of the visual object in the 
current view, changing a symbolic fact in the current 
evaluation environment, bringing a menu of operations 
on the visual object, or a combination of several meth- 
ods. An after-click method (ac) is a method invoked 
when the pointing device selection in the sensor area is 
released. A default method is available to redraw the 
sensor area in the possibly changed evaluation environ- 
ment. 

Following the example of PI above, the following 
defines a before-click method for PI that changes the 
displayed name of PI: 



(in F) environment 

(define be (left -but ton Arcst ignore) (nunc) 
(cond (previous-name) 
(set name previous-name) 
(set previous- name nil)) 



(let 



(set PI environment 
((n 806) 
<y 276) 
(w 88) 
(w/2 44) 
(h94) 
<h/2 47) 

(icon (get-icon "Margaret")) 

(name •'user*')))) 
(dcfine-PreScript PI dl el il si) 
Where: 

dl ■* (;; use two coordinate <x and y) 
(set dimension 2} 
move to the center or the visual object 
(moveto w/2 h/2) 
;; display icon 

(Wit icon (-(/u 131) (.(/h 2.3))) 
;: set the current display font 

(set fonl helvetica 14 bold)) 
;; print name 

(printo name H/w 3)X/h 3)) 
;; draw a box around 
(edges (-w/2) (-h/2) w/2 h/2)) 

el - (circle 0 0 (max » »)) 

i) m (cdjet ('W/2)<.h/2) w/2 h/2) 

si » (cdfei <-w/2) </b J) w/2 h/2). 
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(set previous-name name) 
(set name "Margaret")))) 
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This PreScript object PI is drawn according to dl in 
the let environment of PI on the display device at a 
location centered around the x,y coordinates ($06,276). 
The variable "icon" is displayed at the specified loca- 
tion. The variable "name" is used and printed at the 60 
specified location in Helvetica font (size 14, type bold), 
then a box is drawn. The exterior el is defined by the 
exterior of the circle centered at the coordinates of PI 
and of radius 150. The interior il is the interior of a box 
of width "w" and height "h" centered at the coordi- 65 
nates of PI. And the sensor area si is delimited by a 
smaller box at the bottom of box il enclosing the display 
of "name". 



As a result of this definition and the above default defi- 
nitions of the "in", "ex** and "ac" methods. When the 
pointing device enters the sensor area si of PI (an invisi- 
ble box around the display of "name"), the "in" method 
is invoked and the si box is highlighted. When the 
pointing device is used to make a selection in the sensor 
area of PI, the "be" method of PI is invoked that 
changes the value of "name** in the environment of PI 
to "Margaret" (after storing the current value of 
"name" under a new variable called "previous-name"). 
When the pointing device is released the default "ac" 
method is invoked on PI causing the PreScript element 
dl to be executed in the (changed) environment of PI. 
PI is therefore displayed as a box with the icon at the 
top and the word "Margaret" (the name of a specific 
user) printed in Helvetica font at the bottom. If the 
pointing device is used for a second selection inside si, 
the name of Pi is changed to the value of the variable 
"previous-name" defined in the environment of PI, 
therefore the name "user" is restored as value of vari- 
able "name" in the environment of PI. The "ac" 
method invoked upon release of the second selection 
inside si causes the display of PI to change back to a 
box with the icon at the top and the word **user" at the 
bottom. When the pointing device leaves the si area of 
PI the "ex" default method is invoked and si is not 
highlighted. 

Such click methods are used in GRAS to interac- 
tively design selectable visual representation of actors. 
Buttons, switches and various input/output visual ob- 
jects are thereby provided. Actor composition is used to 
combine these features together into more elaborate 
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system components, for example a phone object is built coordinates. If the transform is linear in a view, it can be 
from a case actor, a set of push-button actors, a crystal expressed using a coordinate transform matrix Mj 
display, and a handset, ({xi} « Mj {xi/viewj}); 

Click methods when defined with arguments are (b) Constraints on the displacement of coordinates in 
selective on the type of selection performed via the 5 the set of views: 
pointing device (e.g. a left-button selection can be de- 
fined differently than a right-button selection). The C: {xi}- >(viewo/cO({»» t view»/ci«xi }),... , 
current environment is used to form the evaluation vk*q/cq({xi))) 
environment for the click methods. The visual object, 

the current view, and the type of selection done in the jo Wewj): <*0- ><#{«)) 
pointing device are passed as arguments to these meth- 
ods. In addition, given a visual object hierarchy (e.g. wherein cj is a constraint function for the actor coordi- 
component relationship), if a visual object A is an infc- nates observed in the j-th view. When a single con- 
rior of visual object B in that hierarchy, then A has also straint function cO is provided to the absolute coordi- 
access to the environment of B by using explicit refer- l5 nate system, then it is assumed that there exist a linear 
ence to its superior attributes. transformation Mj to generate the q views and the con- 

For example if a phone object Phi has a push-button straint function used for each view is: 
PB1 sub-object, then in the environment of PB1, W is 
the width of the push-button and (SUPERIOR W) is cj^cOoMj 
the width of the superior of PB 1, that is Phi, the phone ,0 

object. (c) A set of symbolic translation functions for all the 

The default click-method provides for motion of a views where the actor is represented: 
visual object A in the current view V following the 
constraint function provided for A in view V. The viewj ->uj 

motion is further constrained by the extent of the supe- ~ 

rior of A (in the component hierarchy). The top supe- wherein trj transforms a symbolic characteristic from 
rior of A in the component hierarchy is the video moni- the actor environment (e.g. name, iname ( icon) or the 
tor for view V where the motion of all actors in the name of an element from its local knowledge base (ai) 
present view is contained. into a new name used in the j-th view, the default trans- 

For example if a sub-object CI (cursor) of Phi is in ^ 0 lation function being the identity, 
motion, the movement of CI is limited to the interior An actor's visual representation in the j-th view is 
region of Phi (the "i" element of Phi). obtained by evaluating the first Prescript expression 

An actor's Prescript evaluation environment com- (drawing) of its associated visual object within the ac- 
prises a combination of three environments. tor's Prescript environment knowing that the view is 

1) An environment describing the local knowledge ^ viewj. The actor's Prescript environment is also used to 
base of the actor: evaluate the three other Prescript objects (e,i, t) used to 

define the actor's visual object (respectively exterior, 

A* u] ~ vl w~vn — ) interior and sensor) and to invoke the appropriate sen- 

v ,. . , . A . sor and click-methods during user interaction, 

wherein "ai denotes the symbohc name of a fact in the Gr* V toc*\ changes in all the views are directly de- 
knowledge base and vi is the corresponding value or 40 ^ ^ ^ changes %Q ^ M% know ledge 
expression. .... . . base by PreScript evaluation in the actor environment 

tlc?onh CT ^or e 50 gf at time 1 The Prescript expression describing the 

e ' graphical representation of an actor uses the let envi- 

(kt *ir-v*if. ntmc-vn*™. iname-vmame, 45 ronmem bindings (ai) of this actor. So the value of the 

fccni^viconi xi=vxU2t=v*2 "ai" slots are freely used to specify the PreScript ele- 

»p«vxp. . . . ) ments (d,e,i,s) of the actors PreScript object. This prop- 

erty directly supports display changes that reflect 
wherein "self (the actor itself) is bound to "vself ," a changes in the actor's knowledge base implemented as 
unique identifier for this actor (e.g. its address); M name" ^ the actor i ct environment. A graphical editor may auto- 
is bound to the stage name of the actor, "iname" is ma tically generate the code to associate and combine, 
bound to the internal name of the actor (or symbolic using n^s, these logical changes and graphical effects, 
address); "iconl" is bound to "viconl", an iconic repre- i n ^ dtcnMe implementation, a database of relations 
sentation, i.e., a symbolic identifier for an icon in an icon between logical changes and graphical effects would be 
library, and is used to produce a visual image; "xT are J5 maintained, The user interface of the GRAS system was 
bound to the actor s ordinate* m an absolute coordmate built ^ such visuaJ objects (visual representations of 
system of dimension p in a fixed absolute referential. aclor&) The flexibility of ^ representation is such that 
3) An environment defining a set of transforms and the intcrface to the svstem buiIt ^th visual objects can 
constraints on the actors visual representation and attn- ^ completely redesigned in a few of days. The environ- 
butes for a set of views {viewjX j = 1, q; defined for ment ^ ^ lQ ^ itf own falerf ch 
d fT VCft t ^ws CtnPnS,ng: coordinates for bunons |ook ^ fcd a<Jd new buUons and co * respor *. 

1 eren views. comm ands. This is a first step in the process of re- 

T: {«)- >(vic*l/ii({w» view q /tq({xi») designing a VSM-based system within itself. 

During execution, the actors knowledge base history 
T( viewj): {xi)->ij(Ui)> 65 is automatically maintained by the Soft Coder, provid- 

ing for completely reversible execution of graphics and 
wherein tj is the transform function to obtain the coor- states. Each acior has a history of changes of its aitri- 
dinates of the actor in the j-th view based its absolute butes that is automatically maintained for each tape it is 
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used in. The history is a record of effective changes, if Rules can be designed to avoid this problem. There is a 

the actor is not used in a tape, its history is empty for possibility of conflict when the postconditions of an 

that tape. Changes to actor attributes can affect the actor executed in parallel would result in multiple 

graphical representation of the actor, and the only changes to the same attribute in the current actor envi- 

changes possible to an actor's visual representation 5 ronment Such conflicts are easily detected at run-time 
during the simulation of a tape are via changes to its- and may be resolved using a technique acceptable for 

attnbutes. Therefore the history maintained is a suffi- the ^gct application (e.g. random choice, multiple 

cient mechanism to provide a complete record of both values, change overwrite, error signal), 

the actors internal attributes and its visual represent* Another possible case of conflict occurs when a 

tK>n * 10 viewer removes an actor or changes the description of 

Communication Between Actors M actor during the execution of a Tape Program in- 

- ... ... , . volving this actor. Should the change be local to the 

Commun,cat.o« > »*tween actors is implemented vui of a speciflc scenario or should the change be 

Scnpt Rule execut.on by the SoftCoder. A commuraca- ^ ^ descri tion of the Klor ^ * b8|)! 

ton mcludes transmission of tnforroat.on between ac- ,j ^ fli h revived by prompting the viewer tc 

tors and all computations accompanying the transmis- . . . , , -r, r , r & , 

sion. A degenerate case of communication involves *?? " ° °* a !f 

transmission from an actor to itself and is equivalent to "J! 0 ^ on| y * e ° f A ? J* °™ ^ ? 

internal computation in the actor environment. Two " " the futU / c h,sto ; y , of If 15 

modes of communication are defined: (1) communica- 20 «! oba) ' * e chan « c ,s f f 1 ^ ,ocaI * ™ 6 lf th 5 

tion with mutual agreement and (2) communication not em * X J> th f c l*™ ^ported to the 

with delivery mmaI data *P ace description of A. If the change re- 

(1) Communication with mutual agreement: consider- < uires '^ving a set of Script Rules, depending on the 
ing the case of a Script Rule execution with message acto f that . 15 removed the user is prompted for 
transfer between two distinct actors, the communica- 2 5 > on re ^^ & l ° f th Zl ***** and P 058 * 1 * amo ' 
tion is executed with mutual agreement when the pre- matlc ^winding of the Tape Program execution is per- 
conditions of both sender and receiver actors are satis- fo ™ ed to P^vent unreachabihty conflicts. 

fled at the same time before the message is transmitted. Dunn « the execution of a given Tape Program the 
The communication is also called synchronous and can user ma y decide to r€move a Scn P l Rul€ that has fired 
be represented using: 30 P rcv,ouslv m tnc history of execution, i.e. t there exists a 

Script Instance for this Script Rule. Or the user may 
p(S,R)>M(S.R)>Q(S.R> edit a Script Rule or an actor in a way that would have 

inhibited or triggered its firing or the firing of other 
where S is the sender, R is the receiver, P, M, Q are Script Rules in a different way if the history was re- 
spectively the preconditions, message and postcondi- J5 played. This type of conflict can result in unreachabihty 
tions. A synchronous communication is an atomic com- as above. Editing a rule that has already been used to 
putation in the actor system. build the history of execution can require rebuilding the 

(2) Communication with delivery: given a Script history. The current state of the actor system may not 
Rule, if the preconditions on the sender actor are satis- be reachable using the modified set of rules. In this case, 
fled before those on the receiver actor, the communica- ^ rewinding the execution of the Tape Program is recom- 
tion is performed via delivery. The sender actor issues a mended and re-execution of the old history to check if 
message constructed in the environment of the sender a comparable state of the actor system can be reached, 
actor at the time of precondition satisfaction. The Script 

Instance is then marked using the script type "Sent" the MOVON 
SoftCoder queues the communication for delivery to 45 Actor data-space and history: for practicality of im- 
the receiver actor, and the postconditions of the sender pigmentation, the history maintained for an actor is 
actor are executed. When the receiver actor precondi- based on a measure of data-space changes. Let: 
tion is satisfied, the message is processed by the receiver 

and the postconditions are executed. The communica- ' 
tion is also called asynchronous and can be represented <n , „ : ( * , 

' 50 dD(A. 11, c2) dmDSCA. tl, t2) 

as: -■ m i» ■ . — ■■■■ ■, — i 



P(S)=>M(S, Sent)«>Q(S) respectively, denote the data-space (D) of actor A at 

time t, a measure (the value of mDS is a number) of this 

<Wft,t) 53 data-space at time t, a difference (dD) in the data-space 

jv R)= >M(DcH vcrcd R)= >Q<R) of A the timcs u ™ d t2 » and a measure (dmDS, 

a number) of the data-space change for actor A between 

using the previous notations. M(S, Sent) indicates that " ? ■ * Tl * U °? ° f ? r A T*?*? * 

the message is constructed in the sender environment at deflned " ' « nrte «* changes to the data- 

the time it is sent. M(DeIivered. R) indicates that at the 60 If* ^ or exam P ,e - knowul 8 the ,n,t,al data **P a < :c 

time the message is received by R, the environment of R m aclor A * 

is temporarily augmented to include the environment ^ A (0) 
from the message delivered, then Q(R), the postcondi- 

tions of R are executed in this temporary environment. a f|nile his , of ^ n for ac , or A ^ (e) 

In the general model of communication between 63 can ^ g^fin^ as . 
actors, it is possible for an actor to send or receive and 

process several communications in parallel although if Hc<A)={(ii,dD<A,si.u-i))|dmDS(A.gUi- 

this is not desired for a given application, the Script i)> =e}i = <(= <n 
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and: 

T(He<A))o{li}] = <l=<« 

5 

represent the set of time-stamps from the history of A. 

The intermediate data-spaces of A are then obtained 
using: D(A, tj)=D(A, tO) + {+dD(A, ti, ti- 
l)}i = <i=<jj 

It is also possible to refine the model of actor history to 10 
using a space-efficient description of data-space changes 
for actor A: 

fitgiA) *= i[(ti dXKA. tUti- l))\dmDS(A. ti ti - I) > « t] or J5 
[(ft dIXA. th, ti))\dmDS{A. ti. ti - 1) >~ r] and 
there exist h. 0 « < A < i dmDS{A, tk ti) ■» < g)} 
l»<io<» 

He,g(A) defines a model of actor history with granular- 20 
ity e and efficiency g. The intermediate data-spaces of A 
at time t can then be derived from the history of A 
using: 

if t= <t0 then D(A, t)=D(A,tO) 2J 
if t>tO then there exit (tj.tl) in T(He,g(A)) 
such that 

tj= <tp, for all t\ tj= <t'<tp, t' not in T(He,g(a)) 
then D(A,t) = D(A,tj) « D(A ,ti) + { + dD( A.tik.tik- 
])}0=<k=<K 30 
satisfying: 

1) (tiO, dD(A, tp ( tiO)) is in He,g(A) 

2) for all k, 0= <k= <K (tik, dD(A, tik, tik-l» is in 
He,g(A) 

3) tiK-tj 35 
An actor A is fully specified at time t by its data-space 
description D{ A, t) which is a step-wise function of time 
knowing the actor initial data-space and its data-space 
history. An actor history only lists the times at which 
the actor was changed and the corresponding descrip- 40 
tions of changes to the actor data-space. Actor data- 
space changes of the form (dD) describe the addition of 
new slots and/or new values, and/or deletions of new 
slots and/or new values, and/or changes to values. The 
address of actor A, a(t) is a particular element of the 45 
data-space of A providing a unique identifier for A in 
the actor system. 

Reversibility in an actor system: the actor history 
provides a history management mechanism local to 
each actor. In the system of communication between 50 
actors, an actor data-space can only be changed when 
the actor sends or processes a communication. Further- 
more, sending and processing a communication are 
atomic operations. Therefore the scope of each change 
in the actor system is fully specified with each commu- 55 
nication and the history of all actors can be maintained 
in linear time under the assumption that all actor data- 
space measures are fixed-value bounded. This model 
supports fully reversible computation in the limit of the 
size of actor histories maintained. An important ad van- 60 
tage of this model of computation is the distribution of 
computation history between actors which supports 
reversible computations in distributed actor systems. 

Actor environment: the GRAS implementation of 
actors uses a let environment to represent the data-space 65 
of actor A at time D(A,t): 

(lei tlnvl. . . . ,*n = vn; . . . ) 



where ai is a symbolic representation of a slot of A, vi is 
the corresponding value or expression describing that 
value, and n is the total number of slots at time t, and the 
sign represents an assignment of the value. The 
measure of the data-space of A at time t is: mDS(A, 
t) = n and the history definition used is: H1(A) (e=l), 
An actor environment fully describes the actor at time 
t. The behavior description of an actor is entirely de- 
rived from the actor environment and the behavior 
available from a tape where the actor plays. 

Actor relationships and connections: actors are also 
involved in static and dynamic dependencies imple- 
mented as relations using frame representations with 
bidirectional links. Static dependencies include: clast 
memberships (AKO), component membership (COM- 
PONENT or PART-OF), connections, tape member- 
ship, and others. Dynamic dependencies include con- 
nections between actors (e.g. a line connection for data- 
communication). It should be noted that new types of 
relationships between actors can be defined to fit the 
application domain. Visual representation preferences 
are available as attributes to represent and build new 
relations. A finite set of graphical primitives is used to 
provide (optional) visual representations for each type 
of relation (by combination of the graphics). New rela- 
tions can be dynamically added to an actor as new attri- 
butes are learned and forgotten. Relational attributes 
are the set of actor's attributes used to define relations 
with other actors. An example is the COMPONENT 
relation, where a decomposition of the actor is provided 
in term of components and sub-components. Each com- 
ponent is an actor and can therefore communicate with 
other actors, but a component is also a physical part of 
the actor that owns it (e.g. a phone with a speaker and 
push-buttons). 

VSM Functions 

The GRAS system is implemented on a user level via 
the VSM module. The VSM module comprises user- 
level functions that call upon the lower level modules to 
perform user requests. 

Special Effects: during or after recording, a special 
effects software module is available to refine a rule of 
behavior. For example, in a Script Rule, the actors, 
preconditions, postconditions, message and data trans- 
ferred can be modified. The change, requests are sup- 
plied by tracking-device input and menu selections. 
Additional special effects available to refine a General 
Script include interactive specification of characteris- 
tics (e.g. pattern matching expression on attribute val- 
ues) to generate audit expressions defining the set of 
actor couples for the Genera) Script. 

FIG. 6 is a flowchart diagram of a CREATE TAPE 
function. The create tape function requests a tape visual 
object from MOVON (action block 601). MOVON 
then allocates a frame structure for the new tape named 
(action block 602). MOVON links the frame structure 
to the frame of loaded tapes (action block 604). The new 
tape is made current by linking its frame to the frames of 
video monitors (views) present in the environment (ac- 
tion block 606). The new tape is loaded (see Load Tape) 
into the SoftCoder (action block 606) and is linked to 
the future-reel and the past -reel, the simulation counter 
is internally set. MOVON displays the new tape (action 
block 610) causing the re-display of the video monitors. 

FIG. 7 is a flowchart diagram of a LOAD TAPE 
function. The load tape function determines a tape to be 
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loaded (action block 702). The tape past-reel and future- MOVON then displays the actor in all video monitors 

reel are linked to the past-reel and future-reel elements supporting the same view as the current view where the 

of the SoftCoder resulting in the installation of a script actor was created (action block 1110). 

instance and rules into the SoftCoder (action block 704). FIG. 12 is a flowchart diagram of a SELECT 

The simulation counter is set using the value of the tape 5 ACTOR function. The select actor function requests a 

counter. MOVON displays existing actors from the tape type of actor selection (action block 1201). If a new 

into the appropriate views in video monitors (action object is selected (test 1202) then the create actor func- 

block 706). The SoftCoder does a preliminary evalua- tion is used (action block 1204). If all objects are se- 

tion to optionally set the initial simulation mode, speed lected (test 1202), then MOVON links all actors loaded 

of animation and level of detail (action block 708), The 10 (backstage actors) to the current view and displays 

play function (described subsequently) is invoked (ac- them in the corresponding videomonitors (action block 

tion block 710) and MOVON links actors from the first 1206). If keyword search is used to select actors then 

set of executable scripts to their associated views (ac- the user is prompted to enter a keyword (action block 

cording to the script tags) and displaying the actors, 1208). If matching actors are not found (test 1210), a 

message and data exchanged in the appropriate views 15 new selection is requested (action block 1202). If match- 

(action block 712). ing actors are found then a specific actor is requested 

FIG, 8 is a flowchart diagram of a COPY TAPE (action block 1214) and the actor (if any) is linked to the 
function. The copy tape function first requests a source current view and displayed (action block 1216). 
tape from which a copy is to be made (by default the FIG. 13 is a flowchart diagram of a SET ICON 
current tape loaded), and the function then requests a 20 STATE function. The set icon state function requests a 
destination tape to which to copy the source tape (ac- script from the set of script instances just executed (ac- 
tion block 802). If the destination tape already exists tion block 1302). Then it requests the sender or receiver 
(test 804) and if it is decided to reuse this tape (test 806) actor from the script (action block 1304). MOVON 
then the frame structure of the source tape is merged determines the current icon used by the said actor and 
(with reuse) into the frame structure of the destination 25 retrieves the set of possible icon states for this icon from 
tape (action block 808). If the destination tape does not the icon library (action block 1306). The set icon state 
exist then a new frame structure is allocated (action function then requests an icon state from the set of 
block 810), the frame is linked to the frame of loaded possible icon states (action block 1308), The SoftCoder 
tapes (action block 812), the source tape frame structure undo function is invoked on the script set (action block 
is merged into the new destination structure (action 30 1310), The SoftCoder adds a condition expression to 
block 808). change the state of the actor in the selected script post- 

FIG. 9 is a flowchart diagram of a REMOTE TAPE condition list (action block 1312). The SoftCoder play 
function. The remove tape function determines a tape to function is invoked and MOVON displays the corre- 
be removed (action block 902) and determines if actors sponding change to the actor as a result of executing the 
should be removed with the tape (action block 904). 35 changed script definition (action block 1314). 
MOVON unlinks the frame structure of the tape from FIG. 14 is a flowchart diagram of a CONNECT 
the frame of loaded tapes (action block 906). If actors ACTORS function. The connect actors function re- 
should be removed with the tape (test 908) then the quests a script from the set of just executed scripts (ac- 
f unction removes (deletes) all actors that are used in the tion block 1402) and a type of connection (symbolic 
tape and that are not used in other loaded tapes (action 40 name) (action block 1404). The graphical representation 
block 910). Otherwise, if actors should not be removed corresponding to the type of connection is determined 
with the tape the function unlinks actors used in the tape (e.g. single line, double line, conference line) (action 
that are also used in other loaded tapes, but preserves block 1406). The number of actors to connect is re- 
links to other loaded tapes (action block 912). The func- quested (action block 1408). The actors to connect are 
tion then deletes the tape frame structure (action block 45 requested (action block 1410). The SoftCoder undo 
914), erasing all its links to other frames. function is invoked (action block 1412). A condition of 

FIG. 10 is a flowchart diagram of a RENT TAPE the form: "CONNECT {connection-type} (list of ac- 

FILE function. The rent tape file function requests a tors selected]*' is added to the postcondition list of the 

tape file format and a path to the tape file to rent (action selected script (action block 1414). The SoftCoder play 

block 1002). The number of tapes stored in the file is 50 function is invoked (action block 1416) and as a result of 

determined (action block 1004). The create tape func- executing the changed script, the connections between 

tion (FIG. 6) is invoked for each tape (action block the actors selected is created and displayed in the appro- 

1006). MOVON creates or merges (with reuse) actors priate views. 

required for the topes being created from file (action FIG. 15 is a flowchart diagram of a MAKE AC- 
block 1008). MOVON creates video monitors for each 33 TORS VISIBLE function. The make actors visible 
view required by the tapes and links actors to views function requests a script from the set of just executed 
according to link information from the tape file (action scripts (action block 1502). The actors to create of make 
block 1010). The SoftCoder then creates and links to visible are requested (action block 1504). The Soft- 
each tape the corresponding script structures read from Coder undo function is invoked (action block 1506). A 
the tape file (action block 1012). 60 condition of the form: "VISIBLE {list of actors se- 
FIG. 11 is a flowchart diagram of a CREATE lected]'* is added to the postcondition list of the selected 
ACTOR function. The create actor function requests script (action block 1508). The SoftCoder play function 
the identification of an actor to be created (action block is invoked (action block 1510) and as a result of execut- 
1102). MOVON allocates an actor frame structure and ing the changed script, the actors are made visible (or 
initializes it to include minimum internal and graphical 63 possibly created and made visible) and displayed in the 
attributes (action block 1104). MOVON then links the appropriate views. 

actor frame structure to the current tape (action block FIG. 16 is a flowchart diagram of a SET STATE OF 

1106) and the current views (action block 1108). ACTOR function. The set state of actor function re- 
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quests a script from the set of script instances just exe- the SoftCoder sets the default tag to the requested lag in 

cuted (action block 1602). Then it requests the sender or the video monitor (action block 2014). MOVON then 

receiver actor from the script (action block 1604). displays the video monitor indicating the channel tag on 

MOVON determines the current set of slots from the its display (action block 2016). When recording in this 

said actor the name of a slot is requested (action block 5 video monitor, the tag serves of cross reference be- 

1606). This slot will be used to change the state of the tween the video monitor view and the set script struc- 

actor. A new value is determined for the said slot (ac- tures created in this view. 

tion block 1608). The SoftCoder undo function is in- FIG. 21 is a flowchart diagram of a TRANSLA- 

voked on the script set (action block 1610). The Soft- TION TABLE function. A request for a table operation 
Coder adds a condition expression to change the slot of 10 is sent to the user via the VSM (action box 2102). A 

the actor to the new value in the selected script post- request for a script from the current concurrent group 

condition list (action block 1612). The condition added of scripts is sent (action box 2104). If the sender actor is 

is of the form: W SET {slot-name} {slot-value}". The not identical to the receiver actor (test 2106) an error 

SoftCoder play function is invoked and MOVON dis- message is displayed (action box 2107) via the VSM and 

plays the corresponding change to the actor as a result 15 the function is ended. Otherwise, the script describes an 

of executing the changed script definition (action block internal processing task for an actor (sender —receiver), 

1*16). and a translation table can either be created or edited 

FIG. 17 is a flowchart diagram of a PASS DATA (test 2108). If (test 2108) no translation table expression 

VIA MESSAGE function. The pass data via message exists in the script, the creation of a new translation 

function requests a script from the set of just executed 20 table is necessary. Then a state (slot-1) of the actor is 

scripts (action block 1702). The name of a slot from the selected to be used as entry slot to the translation table 

sender actor of the said script is then requested (action (action box 2110) and a state (slot-2) of the actor is 

block 1704), This slot [slot-from] is used as data to be selected to store the result of the converted value by the 

sent to another actor. The name of a slot [slot-to] from translation table (action box 2112). A list of values for 

the receiver actor is requested (action block 1706). The 25 data conversion is requested (action box 2114). A trans- 

SoftCoder undo function is then invoked (action block lation table is allocated and a (new) conversion expres- 

1708). A form "{slot-from} {slot-from-values}" is sion inserted into the selected script (action box 2116). If 

added to the message expression of the selected script (test 2108) a translation table editing action is selected 

indicating that the slot value of the sender actor is and if (test 2109) no translation table expression exists in 

passed via the message and that it's symbolic name 30 the script then an error message is displayed (action box 

when received is {slot-from} (action block 1708). A 2111) and the translation function is ended. If (test 2108) 

condition of the form: "SET {slot-to} {slot-from}" is a translation table editing action is selected and if (test 

added to the postcondition list of the receiver actor for 2109) there exist a translation table expression in the 

the selected script (action block 1710). The SoftCoder script, then the translation table is displayed by 

play function is invoked (action block 1712) and as a 35 MOVON via the VSM in an editable form and is edited 

result of executing the changed script, the slot value by the user (action box 2113). Then the SoftCoder 

from the sender actor is passed to update the [slot-to] changes the postcondition list of the script to include 

value of the receiver actor and the corresponding the modified translation table expression (action box 

graphics changes are displayed in the appropriate 2115). A translation table expression is of the form; "set 

views. 40 slot-2 (select slot-1 {list of (entry, value-expression) 

FIG. 18 is a flowchart diagram of a CLONE pairs}", (action box 2117). 
ACTOR function. The clone actor function requests an A video monitor is used to display or to record visu- 
actor to be copied (action block 1802). MOVON alio- ally a set of transactions between actors into a tape. A 
cates a frame structure for the actor (action block 1804). video monitor may display or record a simplified view 
MOVON creates an address for the actor copied using 45 of the system being simulated or created. Video moni- 
the name of the original actor and a copy number that tors have channel controls used to switch between 
makes the address unique (action block 1806). MOVON views and controls for level of detail to provide a mech- 
links the new actor to the current view and display the anism to zoom in and out of a particular part of a play, 
copied actor in all video monitors with the same view In the record mode, channel control changes corre- 
ction block 1808). 50 spond to a change of camera to get a different view 

FIG. 19 is a flowchart diagram of a MERGE point or perspective on the scene, level of detail varia- 

ACTOR function. The merge actor function requests tions correspond to zoom in and out control on the 

one actor {act-from} to be merged into another actor camera. The video monitors have a variety of charac- 

{act-to} (action block 1902). MOVON merges the actor teristics that can be set and changed dynamically. For 

frame structures (action block 1904). The SoftCoder 55 example, a user can set a video channel. Changing the 

substitutes all references to the address of act-from by channel in a monitor changes the view presented in it. 

the address of act-to (action block 1906). The following characteristics: size, colors (where avail- 

FIG. 20 is a flowchart diagram of a SET CHANNEL able), title, animation level and speed, memory size or 

function. The set channel function requests a video how many events are "remembered" on the monitor at 

monitor to change its channel (action block 2002) and 60 a time (persistence), a static versus dynamic display, 

requests a channel selection (action block 2004). If the resolution or level of detail displayed, and default mes- 

channel selected is "all channels" (test 2006), then the sage name position (which changes the default position 

SoftCoder sets the default Script Structure tag to be of the message display relative to the sender and re- 

"Sid" in the video monitor (action block 2008) and ceiver actors) can all be selected by the user via menu or 

MOVON displays the video monitor, leaving the chan- 65 icons from the Video Monitor. 

nel designation empty (action block 2010). If the chan- A video monitor can be used to: play, animate, or 

nel selected is a new channel, the corresponding Script display a tape, record or sei the stage for a transaction. 

Structure tag is determined (action block 2012). Then The VSM interface provides direct control over tape 
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creation, editing, viewing and execution. Changes can 
be incorporated during the execution by recording new 
specification input. While recording or playing, the 
level of detail in the tape can be varied (e.g. using a slide 
bar), providing a looming effect between high level and 
detailed views. A video monitor serves as a dra- 
wing/editing board to change events and the special 
effects being animated in "play" mode. A video monitor 
can display hundreds of objects at the same time. Usu- 
ally, fewer than 20 or 30 visual objects is a rule for good 
visual schematics based on standard graphics display 
technology. If more than 30 objects are needed in a 
tape, special effects can be used. With special effects, 
individual visual objects can become visible or invisible 
as desired. 

A video Monitor in GRAS is implemented using 
windows to support multiple viewpoints. Because some 
design specifications are large, projections (multiple 
views) are supported to hide unnecessary information 
(or complexity) from the user. The GRAS system sup- 
ports simultaneous recording and animation in multiple 
views. Each video monitor has a Video Channel and a 
Level of Abstraction used for recording and animation. 
To support windows and graphics and implement video 
monitors, as well as visual objects, a specific window 
and graphics system is used depending on the target 
computer system (e.g. Sun View TM , X Window Sys- 
tem tm, OPEN LOOK TM , Symbolics Windows, 
Xerox Windows), SunView is a trademark of Sun Mi- 
crosystems. X Window System is a trademark of MIT. 
OPEN LOOK is a trademark of AT&T. 

One application of the multiple viewpoints feature 
provides zooming between an abstract and a detailed 
view. For example, a customer of a proposed feature 
would see the high-level, abstract view. A feature de- 
veloper would use the detailed view showing internal 
switch structure. Two views may be used to separate 
"hardware 11 and "software" behavior. 

Use of windows is enhanced by using the GRAS 
windows and others. For example, a Sun workstation 40 
under SunView can have up to 64 windows. GRAS on 
Sun can use a dozen Video Monitor windows, while the 
remaining windows may be used by other Sun View 
applications (mail, text editing, and others) running at 
the same time as the VSM/GRAS application. 

A Lisp machine may have several hundred windows 
(the number is only limited by disk space). 
VSM/GRAS on Lisp machines can have as many 
Video Monitors as desired (e.g. multiple views). This 
concept is similar to having several TV monitors tuned 
to different channels to provide different views of the 
execution of the same or different scenarios. 

An Editing Room provides direct access to Tapes of 
the Tape Shelf and a set of operators used to edit and 
manipulate Tapes using a video-tape or film editing 55 
analogy. Tape editing provides a unique support for 
program manipulation. Based on execution context 
closure provided by the implementation of an actor and 
its environment, and its use in the processing of commu- 
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also provided but requires more caution since the tape 
must be cut at a position where both sub-tapes are left 
closed and consistent Cutting and gluing of tapes pro- 
vides a simple mechanism to combine functionality 
from different work efforts. Combined with the capabil- 
ity to merge actors, this provides a powerful framework 
to address successive integrations of new features in a 
program system. 

SoftCoder 

The Soft coder module of GRAS comprises a Future- 
Reel, comprising the set of Script Rules and General 
Scripts of a Tape Program, and a Past-Reel comprising 
a set of Undoable Scripts tracing the execution history 
15 of a Tape Program. In a Past-Reel, all Script Instances 
are reverse executable, i.e., the Sundo and Rundo ex- 
pressions arc present in all Script Instances. The Past- 
Reel contains the history of execution and data input 
during this execution, it may therefore be used as a test 
scenario. 

FIG. 29 gives a visual representation of the Soft- 
Coder. A Tape is a set of recorded Script Rules and 
General Scripts, the past-reel 2910 corresponds to 
Script Instances that have been selected and fired by the 
simulator before the current simulated time, the future- 
reel 2920 contains remaining rules or the complete Tape 
Program in Production mode of simulation. Each reel 
turns clockwise and is advanced one or more steps at a 
time during simulation. The Fixed (Play) head 2930 
reads and executes the current set of Script Rules and 
General Rules. The Undo head 2950 marks the Script 
Instances with undoing information. The Record head 
2940 is available at all times to record and insert new 
rules. The Look-Ahead head 2960 is used in simulation 
to look for the next set of rules to fire. 

The SoftCoder comprises a "control panel' 1 with the 
following controls: 

Autoplay: plays the tape program from its current 
position to the end (or until a stop) automatically at the 
selected animation speed. FIG. 22 is a flow diagram of 
the autoplay control function. The autoplay function 
repeatedly invokes the play function (action block 2202) 
until the end of the tape program is reached or the stop 
function has been invoked since autoplay started (test 
2204). 

Play: plays the tape one step (frame) at a time by 
executing the set of rules of behavior currently fireable. 
FIG. 23 is flow diagram of the play control function. 
The play function identifies the following variables 
defining the play context (action block 2902): current 
tape loaded and its reels (future-reel and past-reel), 
current speed of animation, simulation mode, animation 
and simulation levels. In the play context the function 
then finds the eligible set of Script Rules and General 
Scripts from the future-reel (action block 2303) (see the 
following detailed description of this operation as a 
function of the simulation mode). If the set of scripts is 
empty (test 2304) the user is informed that the end of the 
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nications between actors, each Script Structure can be 60 tape program is reached (action block 2305) and the 



treated as an independent atomic computation per- 
formed by the SoftCoder virtual machine and can be 
manipulated as a basic program element. In a Tape 
Program, a closed set of Script Structure is always 
present. By gluing two tapes one possibly obtains the 65 
addition of functionality from both tapes, this makes 
feature integration a semi-automatable procedure in the 
context of GRAS. Cutting a tape into two sub-tapes is 



play function is ended. If more scripts are available (test 
2306), the user is informed that other variants of the 
tape program execution are possible (action block 2307) 
and the play function is ended. If the eligible set of 
scripts is not empty (test 2304) then the scripts are 
played (action block 2310) (see following detailed de- 
scription) and if the animation speed requires the simu- 
lator to wait (test 2308), a time delay is introduced (ac- 
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tion block 2309) before playing the scripts and then 
ending the play function. 

Record: records new communications and inserts 
them automatically at the current tape location. FIG. 24 
is a flow diagram of the record function. The record 5 
- function first identifies the following variables to de- 
fined the record context action (block 2402): current 
tape program, current views and channels, current ani- 
mation, simulation and recording levels. The record 
function then requests a sender actor for the new com* 10 
munication being recorded (action block 2403). If a 
sender is specified (test 2405) then it is identified (via an 
audit process) or created (action block 2406), else the . 
record function is ended. Knowing the sender actor, the 
record function then requests a receiver actor (action IS 
block 2407). If a receiver actor is specified (test 2408), it 
is identified or created (action block 2409), else the 
record function is ended. Then the record function 
requests a Script Rule to be chosen (action block 2410). 
If no script is specified (test 2411) the record function is 20 
ended, else a Script Rule or a General Script is created, 
if it does not exist, or cloned from an existing one (ac- 
tion block 2412). The new script is inserted into the tape 
program future-reel (action block 2413) and the play 
function is invoked (action block 2415). If the stop func- 25 
tion has been invoked since the last record function (test 
2416), the record function is stopped, else the record 
function restarts (action block 2401). 

Stop; terminates the current automatic execution, 
recording or undoing of a tape. FIG. 25 is the flow 30 
diagram of the stop control function. The stop function 
is interrupt driven: if the stop button is depressed (test 
2502) then a stop event is queued (action block 2503). 
As described, the play (autoplay), record and undo 
(autoundo) functions also check for stop events. 35 

Counter: indicates the number of steps executed since 
the beginning, of the tape. The counter is both an input 
and an output device. Setting the counter value to a 
particular position automatically advances or rewinds 
the tape to that position. FIG. 26 is a flow diagram of 40 
the counter control function. The counter function can 
be invoked two ways (test 2602): 1) for display or for 
setting. For display, the counter function gets the cur- 
rent simulation count, which is the number of simula- 
tion time units elapse since the beginning of the current 45 
tape program (action block 2604) and updates the 
counter display (action block 2605). For setting the 
counter, the counter function requests a counter value 
(action block 2606). If the counter value is greater than 
the current simulation count (test 2607) then the auto- 50 
play function is invoked until the desired counter value 
is reached, the stop function is invoked, or the end of 
the tape is reached (action block 2608). Otherwise, the 
autoundo function is invoked until the desired counter 
value is reached (action block 2609). 55 

Undo: cancels the effects of the last set of communi- 
cations Qa&X set of script instances fired). Rewinds the 
last step and reverses the effect of the last group of 
computations. FIG. 27 is a flow diagram of the undo 
control function. The undo function identifies the undo 60 
context from the following variables (action block 
2702): simulation mode, simulation level, current tape 
program (future-reel and past-reel), multiple views and 
animation levels. The undo function then gets the set of 
script instances to be undone from the past-reel (action 65 
block 2703). For the set of script instances to be undone, 
the undo function then: 1) restores the data-spaces of all 
actors involved in the set of scripts to the their data- 
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space at a simulation time prior to execution time of this 
set of scripts, and 2) if the script instances had visual 
side-effects, execute the corresponding graphics undo 
functions (action block 2704). The undo function then 
removes the script instances from the past-reel (action 
block 2705) and updates- the current -simulation count 
and the current set of scripts (action block 2706). Fur- 
ther explanation on the undo function appears in the 
detailed description of simulation modes following. 

AutoUndo: provides automatic rewinding to the be- 
ginning of the tape or until you "stop" the tape with the 
Stop button. AutoUndo also fully reverses the effect of 
Autoplay at the selected animation speed. FIG. 28 is a 
flow diagram of the autoundo control function. The 
autoundo function repeatedly invokes the undo func- 
tion (action block 2802) until the past-reel is exhausted 
or the stop function is invoked (test 2804). 

Undo and AutoUndo are complete undo mechanisms. 
The effects of playing (and its visual side effects) are 
completely undone while using either control. This 
provides a simple and effective approach to debugging 
and testing. A scenario can be stopped in the middle, 
rewound to a specific point, altered and continued for- 
ward in a few mouse clicks. Dynamic animation of 
object state changes and transactions provide continu- 
ous visual feedback while debugging, testing, or simply 
viewing a feature in action. 

A specification error will trigger a printed warning 
message that warns the user that the following part of 
the simulation may be erroneous or become inconsis- 
tent. The user is free to ignore this (temporary) incom- 
pleteness and continue with other elements of the de- 
sign. Simulation errors are caused either by erroneous 
data or by incorrect rules and rule combinations: the 
user can use undo and play to browse through the speci- 
fication and locate erroneous data or rules, then edit 
them on the spot and continue the simulation using play. 

The use of the SoftCoder virtual machine within the 
VSM permits a user to specify a program from exam- 
ples of its behavior. A graphical simulation in the VSM 
is not a simple sequence of graphical frames but a "pro- 
grammable movie/* i.e., depending on user input data 
the conclusion of the movie may turn out differently. 

The sequential execution of each step of a specific 
scenario replays the example as it was input, but as 
modified by previously supplied actor input or other 
example scenario input pertaining to the specific sce- 
nario. The behavior described by the example may be 
interactively refined into a program through the addi- 
tion of further actor data and/or additional example 
scenarios. The behavior of the actor system changes as 
actor states change and new data is exchanged between 
actors. The actors and Rules of Behavior can be edited 
at any time to change, delete or add other information 
about the state of the actor, the computation performed 
and the information exchanged during a communica- 
tion. At the user's discretion, actor state and graphical 
representation changes may be either permanent or 
local (reversible). The resulting rules form the Tape 
Program, 

SoftCoder Simulation Modes 

A Tape Program is a collection of Script Rules and 
General Scripts, but it is also a collection of behaviors 
with (partial) precedence ordering. Total ordering of a 
tape is only found at run time by simulation of the Tape 
Program which results in the creation of a Tape Sce- 
nario. The SoftCoder has four simulation modes, These 
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are (1) sequential (2) smart, (3) concurrent, and (4) fireable rule is found, play is stopped and the user in 

production modes. informed that the end of the tape program was reached. 

The four simulation modes correspond to four differ- J). When recording, r(t) points to the rule just re* 

ent ways to play the same tape, that is, to execute a corded. r(t) is pushed on the FR stack and the next step 

given specification. These four modes correspond to 5 is played at timet. 

progressive refinement steps, starting with a simple 4). When undoing one step, u(t) points to the next rule 

sequential scenario and ending with an executable rule- to undo Ul, the visual effects of this rule are undone, 

base that can simulate a given feature in various situa- including the optional message display, the undo ex- 

tions (different data, different threads of execution, pressions of its actors are executed restoring them to 

error handling, concurrency). 10 their initial state-before this rule fired. The undo expres- 

A visual representation of the sequential simulation sions are removed from u(t), the original type of the rule 

mode is shown in FIG. 30. The sequential simulation is restored and it becomes f(t), the PR stack is popped 

mode plays each Script Rule and General Script in the once and f(t) is pushed on the FR stack where it be- 

order the tape was originally recorded. The fixed-head comes Rl, t is decremented by a time unit. 

3030 is always positioned on the last script fired. 15 5). To autoplay, the play step is repeated until the FR 

A visual representation of the smart simulation mode stack is empty and no other rule is recorded, 

is shown in FIG. 31. In the smart simulation mode each 6). To autoundo, the undo step is repeated until the 

Script Rule is tested before execution to see if it should PR stack is empty. 

logically be executed (fired) from the current tape stage. 7). To stop, the current autoplay or autoundo se- 

The first Script Rule that can be fired is fired, and is 20 quence is interrupted after the last complete rule execu- 
moved from the future-reel 3120 to the past-reel 3110 of tion or undoing (e.g. when the uninterruptible parallel 

the tape; intermediate Script Rules are skipped. execution of the communication between actors is com- 

A representation of concurrent simulation mode is plete). 

shown in FIG. 32. The concurrent simulation mode is In the smart simulation mode each Script Rule is 

an extension of the smart simulation mode. In this mode, tested before execution to see if it should logically be 

each Script Rule is tested before execution to see if it executed (fired) from the current tape stage. The first 

can be logically fired from the current tape state. Often Script Rule that can be fire is fired, and is moved from 

there is a group of Script Rules that can be fired simulta- the future-reel to the past-reel of the tape, intermediate 

neously. The concurrent simulation mode allows the 30 Script Rules are skipped. 

Script Rules to be fired at the same time using parallel The smart mode is implemented as follows; 

execution. 1). PR(t) and FR(t) represent the current contents of 

The production simulation mode is an extension of two stack objects, 
the concurrent simulation mode, where the tape is glued 2). To play the next Script Rule; at time t, f(t) is 
into a closed loop and sequences of Script Rules and 35 bound to rule Rl which is at the top of the FR stack, the 
General Scripts can fire repeatedly. This mode is similar preconditions of this rule are checked; if they are not 
to a classic production rule system with parallel firing. satisfied, the FR stack is popped and Ht) is pushed onto 
In addition, this production mode supports time depen- PR (this rule is not changed to type Undoable), if the 
dencies and fully reversible execution. A loop formed preconditions are satisfied, this rule is prepared for un- 
by a set of Script Rules repeatedly firing will continue 4Q doing by constructing and storing undo (restore) ex- 
to execute until a termination condition is met (e.g. a pressions for its actors and for its visual effects (a set of 
counter reaches a predetermined value). graphics undo commands), the rule is marked of type 
Let: PR and FR denote the Past and Future reels of Undoable and becomes u(t). The message of f(t)=Rl is 
the current tape program loaded in the SoftCoder. Let: then sent from the sender actor to the receiver actor, 
f,r,u, and la be the fixed, record, undo and look-ahead 45 the postconditions from f(t) are executed (changing 
head of the SoftCoder, respectively. some attributes of its actors), the corresponding visual 
At time t: effects are displayed, the FR stack is popped once, and 
PR(t)=(Ul, U2, . . . , Unt) u(t) is pushed into the PR stack where it becomes Ul, t 
FR(t) = (Rl, R2, . . . r Rpt) is incremented by a time unit. If no fireable rule is 
The sequential simulation mode plays each Script Rule 50 found, play is stopped and the user is informed that the 
and General Script in the order the tape was originally end of the tape program was reached, 
recorded. The fixed-head is always positioned on the 3). When recording, r(t) points to the rule just re- 
last script fired. corded, r(t) is pushed on the FR stack and the next step 
The sequential mode is implemented as follows; is played at time t. 

1) . PR(t) and FR(t) represent the current contents of 55 4). When undoing one step, u(t) points to the next rule 
two stack objects. to undo Ul, If Ul is not of type Undoable. the stack PR 

2) . To play the next Script Rule: at time t, f(t) is first is popped and u(t) is pushed onto FR. If Ul is of type 
bound to rule Rl which is at the top of the FR stack, Undoable, the visual effects of this rule are undone, 
this rule is prepared for undoing by constructing and including the optional message display, the undo ex- 
storing undo (restore) expressions for its actors and for 60 pressions of its actors are executed, restoring them to 
its visual efTects (a set of graphics undo commands), the their initial states-before this rule fired, the undo expres- 
rule is marked of type Undoable and becomes u(t). The sions are removed from u(t), the original type of the rule 
message of f(t)=Rl is then sent from the sender actor to is restored and it becomes ftt), the PR stack is popped 
the receiver actor, the postconditions from f(t) are exe- once and f(t) is pushed on the FR stack where it be- 
cuted (changing some attributes of its actors), the corre- 65 comes Rl, t is decremented by a time unit, 
spending visual effects are displayed, the FR stack is 5). To autoplay, the play step is repeated until user 
popped once, and u(t) is pushed into the PR stack where input is required or the FR stack is empty and no other 
it becomes Ul t is incremented by a time unit. If no rule is recorded. 
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6) . To autoundo, the undo step is repeated until the 5). To autoplay, the play step is repeated until user 
PR stack is empty. input is required or the FR stack is empty and no other 

7) . To stop, the current autoplay or autoundo se- rule is recorded, 

quence is interrupted after the last complete rule execu- 6). To autoundo, the undo step is repeated until the 

tion or undoing (e.g. when the uninterruptible parallel S PR stack is empty. 

execution of the communication between actors is com- 7). To stop, the current autoplay or autoundo Re- 
plete), quence is interrupted after the last complete rule execu- 
The concurrent simulation mode is an extension of tion or undoing (e.g. when the uninterruptible parallel 
the smart simulation mode. In this mode, each Script execution of the communication between actors is corn- 
Rule is tested before execution to see if it can be logi- 10 plete). 

cally fired from the current tape state. Often there is a The production simulation mode is an extension of 

group of Script Rules that can be fired simultaneously. the concurrent simulation mode, where the tape is glued 

The concurrent simulation mode allows the Script into a closed loop and sequences of Script Rules and 

Rules to be fired at the same time using parallel execu- General Scripts can fire repeatedly. This mode is similar 

tion. IS to a classical production rule system with parallel firing. 

The concurrent mode is implemented as follows: In addition, this production mode supports time depen- 

1) . PR(t) represents the current contents of a stack dencies and fully reversible execution. A loop formed 
object, and FR(t) is the contents of a stack-sequence by a set of Script Rules repeatedly firing will continue 
object combination, that is FR is a stack so that it can be to execute until a termination condition is met (e.g. a 
pushed and popped and is also a sequence so that it can 20 counter expires). The production mode is implemented 
be searched and modified by direct access without pop- as follows: 

ping and pushing. 1). PR(t) represents the current contents of a stack 

2) . To play the next Script Rule: at time t, f(t) is object, and FR(t) is the contents of a sequence-hash_ta- 
bound to rule Rl which is at the top of the FR stack, the ble-lattice object combination. FR is analogous to a 
preconditions of this rule are checked, if they are not 25 sequence so that it can be searched through efficiently, 
satisfied or if the rule is already marked of type Group, FR is a hash table or a kind of key-encoded computer 
the FR stack is popped and f(t) is pushed onto PR (this object, so that a Script Rule can be efficiently retrieved 
rule is not changed to type Un doable); if the precondi- from its symbolic reference (Sid) no matter how many 
tions are satisfied (the rule is said to be fireable at time Script Rules are stored in FR. It is a lattice where Script 
t), it is the first fireable rule, f[t) is marked of type Group 30 Structures have been preordered based on precomputed 
and added to its own Group-Saddresses field; it remains logical dependencies between one another so that the 
as f(t), and la(t) is applied to FR(t). If no fireable rule is next set of rules that can fire after a given subset of rules 
found, play is stopped and the user is informed that the is know to be included within a limited subset of FR. In 
end of the tape program was reached. The look-ahead production mode, FR is not altered (e.g. via pop and 
procedure, la(t) does a fast search through FR(t) to 35 push) during play, autoplay, undo or autoundo. How- 
gather all the other fireable rules at this time, each rule ever, FR is changed and reorganized during record and 
found is marked of type Group, the set of rules found by erase (delete) of Script Rules. Assuming no recording 
fa(t) is then joined with the current Group-Saddresses or erasing occurs during play or undo, let FR=(R 1, R2, 
set of f(t) (which is initially {f(t)}). The f(t) rule of type . . . , Rp). At timet, let SFR(t) = S(FR, t)=(RI, R2, . . 
Group is prepared for undoing by constructing and 40 . , Rpt) with pt< =>p, be a finite subset of Script Rules 
storing undo (restore) expressions for all its actors (ac- from FR that are candidates to fire at time t. SFR is 
tors from its Group-Saddresses set) and for its visual derived from the FR lattice knowing the rules that fired 
effects (sets of graphics undo commands), the rule set is prior to t. 

marked of type Undoable Group and becomes u(t). The 2). To play the next Script Rule: f(t) is bound to rule 

message set from the Group-Saddresses of f(t)=Rl is 45 Rl which is the first rule from SFR(t), the precondi- 

then sent in parallel from the sender actor set to the tions of this rule are checked, if they are not satisfied, 

receiver actor set, the postconditions from the f(t) the rule is ignored and f(t) is bound to an instance of the 

Group-Saddresses are executed in parallel in separate next rule from SFR(t), which is checked until either f(t) 

context for each rule in the set, changing some attri- is a fireable rule or all rules from SFR(t) have been 

butes of corresponding actors, the corresponding visual 50 unsuccessfully checked. If no fireable rule is found at 

eiTects are displayed, the FR stack is popped once, and this time, f(t) is bound to an instance of a rule of type 

u(t) is pushed into the PR stack where it becomes Ul, t Wait and Undoable, f(t) is pushed onto PR, t is incre- 

is incremented by a time unit. mented by a time unit. If the preconditions of f(t) are 

3) . When recording, r(t) points to the rule just re- satisfied, i.e., the rule is fireable at time t, it is the first 
corded, r(t) is pushed on the FR stack and the next step 55 fireable rule from SFR, f(t) is replaced by an instance of 
is played at time t. itself to prevent changing the original rule, is marked of 

4) . When undoing one step, u(t) points to the next rule type Group and added to its own Group-Saddresses 
to undo Ul. If Ul is not of type Undoable, the suck PR field. It remains as f(t), and la(t) is applied to SFR(t). 
is popped and u(t) is pushed onto FR. If Ul is of type The look-ahead procedure, la(t) does a fast search 
Undoable, in parallel for the rules of the Group-Sad- 60 through SFR(t) to gather all the other fireable rules at 
dresses of u(t), the visual effects of each rule are undone time t, each rule found is collected as an instance of 
(including the optional message display), the undo ex- itself marked of type Group, the set of rule instances 
pressions of its actors are executed restoring them to collected by fa(t) is then joined with the current Group- 
their initial state-before this rule fired, the undo expres- Saddresses set of f[t) (which is initially {f(l)». The f(t) 
sions are removed from u(t), the original type of each 65 rule of type Group is prepared for undoing by con- 
rule is restored and the top rule becomes fl[t), the PR structing and storing undo (restore) expressions for all 
stack is popped once and f(t) is pushed on the FR stack its actors (actors from its Group-Saddresses set) and for 
where it becomes Rl, t is decremented by a time unit. its visual effects (sets of graphics undo commands), the 
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rule set 15 marked of type UndoabJe Group and becomes conditions are defined. A new message is then specified 

u(t). The message set from the Group-Saddresses of (typed-in by the user) or selected via menu and key- 

f(l)— Rl is then sent in parallel from the sender actor set word search through a set of existing Script Structure, 

to the receiver actor set, the postconditions from the fl(t) if a new message is specified, the Message field of RO is 

Grpup-Saddrcsses are executed in parallel in separate 5 filled-in with the message specified. If an existing Script 

context for each rule in the set, changing some attibutes Structure R 1 is selected, instances of the preconditions, 

of corresponding actors. The corresponding visual ef- postconditions and message expressions of Rl are cre- 

fects are displayed, and u(t) is pushed onto the PR stack a ted and are used to fill-in the corresponding fields in 

where it becomes Ul, t is incremented by a time unit. ro. In either case, the preconditions of RO are altered 

3) . When recording, r(t) points to the rule just re- 10 whcn necessary to insure that the newly recorded rale 
corded, r(t) is inserted in the FR lattice as an element of & ^jy to firc M a consequence of the previous set of 
SFR(t), the lattice is recomputed to restore preordering fircd . For cxamp | Cf if R0 is recorded after R2 fired 

e ne ? ! st€p B p,ayed at Ume 1 * default precondition suting "RO must fire after Rr is 

4) . When iindoing one step, u(t) points to the next rule generated in the target rule description language. 

to undo U l If U l is not of type Undoable, there is an 15 Rulc Insclti on ; At this point, rule RO is ready for 

J " ? t/PC Un ^ blc and W< V l « T V * d,s : insertion in the future reel. In sequential, smart and 

carded and t is decremented by a time unit. If Ul is of ^nounon modes, RO is simply pushed onto the FR 

type Undoable and not Wait (Group), then m paralle sUck , two rcoording modcs J e ^ 

for the rules of the Group^addresses of u{ ) the yisud 1} fa * mod ^ ^ in ^ R that uscd to 

h^i "S " C " ndone ' includm * thc T 0aBl 20 depend on precedents of RO of fire (that is Rl in the 

message display, the undo expressions of its actors are flb £ e exan £, c) m aulomaticalIy up ^ tcd to now de . 

executed, restoring them to their initial state-before this ' p7fnr « 

»u~ ...A ^ m - „ „ M , e M pend on RO for finng. So the preconditions of certain 

rule fired, the undo expressions are removed from u(t), ■ FR chanced 

the original type of each rule is restored and the top rule ruire m rn are cnangea. TO . JWrt 

becomes «t) t the PR stack is popped once and *) re- 25 . £ In raUel ""ft ™ mlt from ™ * * 0 

mains as is, t is decremented bya time unit. 'l*'"^! 'P**** X ° f £ C "5 ^L' 1 ™ ih otncr J rules 

5) . To awoplay, the play step is repeated until user < h * 1 ^ have normally fired after its precedents 
input is required or the Stop button is depressed. < ft * cr R1 111 ! hc example) In production mode, 

6) . To autoundo, the undo step is repeated until the J 10 . 15 ,nserted ** ^ dement m SFR(t), changes in the 
PR stack is empty. 30 latt,cc structure of FR are automatically computed, 

7) . To stop, the current autoplay or autoundo se- the " depending on the recording mode: 

quence is interrupted after the last complete rule cxecu- ! >' H connected mode, all rules in SFR(t) that used to 
tion or undoing (e.g. when the uninterruptible parallel depend on precedents of RO to fire (that is Rl in the 
execution of the communication between actors is com- above example) are automatically updated to now de- 
plete). 35 pend on RO for firing. So the preconditions of certain 

3. Recording, Erasing, and Querying for Rules of rules in SFR(t) are changed and changes are propagated 

Behavior Several advantages in the use of GRAS and in ln the organization of the FR lattice, 

the power of execution of the SoftCoder are derived 2 )' In pa»M mode, no rule from SFR(t) is changed, 

from the flexibility to make changes any time and auto- R0 is therefore expected to fire in parallel with other 

matically validating them in a reasonable time, limited 40 from SFR(t) that would have normally fired after 

to the computation power of the machine. The play and its precedents (after R 1 in the above example), 

undo mechanism described above are examples of such To erase existing rules of behavior, the basic opera- 

a flexible computation model provided by the Soft- tion provided by the SoftCoder permits the user to 

Coder. The ability to record new communications be- remove the last Script Rule that fired. If this last rule is 

tween actors in the middle of the simulation of a tape 45 of tv P* Group, the user is prompted for selecting one 

program or to remove irrelevant rules of behavior are r^e from the set. The tape program is then undone by 

other examples of the power of the SoftCoder approach °ne step and the selected Script Structure is removed 

to specification, system design and testing. from FR (or SFR in the production mode). Then all 

To record a rule of behavior between actors requires rules that used to depend on the removed rule to fire are 

three steps: 30 given a best fit replacement rule to depend upon for 

1) . Visual programming: a basic Script Structure is firing. In the production mode, the lattice structure of 
generated using necessary information collected via FR is then reorganized and a new preorder between 
visual clues, type-in, and menu entries. rules may result. Then the tape program is played one 

2) . Rule insertion: the new Script Structure is inserted step to display the effect of the change; another rule is 
in the current rule base (FR or SFR). 55 likely to fire in place of the removed rule. To erase 

3) . The modified tape program is played one step larger chunks of the rule set, the Film Editor provides a 
further (as described in the previous section). way to cut a portion of the rule set and discard it. 

Visual Programming: A basic Script Structure, RO is A query of the existing rule set for the future or past 
built from selecting a sender and a receiver actor from execution of a certain type of (or subset of rule) pro- 
one of the video monitors currently active on the 60 vtdes a mechanism to quickly position the execution of 
GRAS display, or via menu selection and keyword a tape program at a point of interest for the user. Using 
search, or by selecting audit expressions to retrieve the SoftCoder advanced program execution features, it 
actors from the backstage. The audit expressions may be is possible to request automatic positioning of the tape 
edited and customized by the user. The R0 Script St rue* program at a point of interest in the execution history of 
ture is given a new symbolic reference (Sid), the Sender 65 future. This can be done by recording a visual query 
and Receiver attributes are filled-in with the actors (or that describes an example of a point of interest and 
actor audit descriptions) selected, the Preconditions of searching for a matching sequence of executed rules in 
the sender and receiver default to T (true) and no post- PR first and position the tape via autoundo the required 
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counter location if such matching is successful, else by 
starting the execution in autoplay until a match is found. 

Video Connectors 

A Video Connector is a .software communication 5 
protocol combined with a physical or virtual data-link 
between a foreign system and GRAS. A Video Connec- 
ter is analogous to the coaxial cable linking a source of 
a video signal (camera, mixer, TV-cable) to a VCR. 
However, in VSM, a Video Connector provides a com- 10 
munication path for both recording events from an 
external system into a Tape, and remotely controlling 
GRAS from the external system. 

ORAS can record specifications from user interac- 
tions from all Video Monitors, as a camera following 15 
the user sketching (specifying) transactions. Each 
Video Monitor during recording is part of a Video 
Studio where actions between actors arc recorded by 
the camera. The camera in a Video Studio is linked to 
the SoftCoder by a virtual Video Connector. 20 

The Video Connector interface is implemented in 
such a way that an application can send data-traces to 
GRAS and remotely control GRAS at the same time. 
For example, the application can create a new Tape, 
start remote recording of the Tape (i.e. queuing mes- 23 
sages), change the level of detail, change the animation 
view, and GRAS will start animating the trace in syn- 
chronous or asynchronous mode. If desired, the appli- 
cation can fully control the graphical representations 
used. The remote control of GRAS is based on a stan- 30 
dard Remote-Evaluation protocol (remote function 
call) that can be supported by any bidirectional data- 
link. 

OOScripts 3J 

An OOScript is the atomic entity that defines a single 
transaction between two actors. An OOScript is the 
smallest entity describing one aspect of an actor's be- 
havior. Each OOScript describes one rule of behavior 
involving one or two actors known as Sender and Re- 40 
ceiver. 

Formally, an Object-to-Object Script (OOScript) is 
defined as a mathematical tuple (sid, sender, receiver, 
precond-list, postcond-list, message, optional documen- 
tation). Each OOScript is associated with a unique iden- 45 
tifier (sid); (sender) refers to the entity that invoked 
(message) to call (receiver); (precond-list) provides the 
preconditions that must be satisfied for the OOScript to 
be activated; (postcond-list) provides the postconditions 
of a system that are asserted true after the OOScript has 50 
completed execution; (message) is the name of the mes- 
sage or function invoked, with optional arguments; 
optional documentation can include comments on the 
transaction represented or the objects involved. 

The syntax of OOScripts is the following: Both pre- $5 
cond-list and postcond-Iist are enclosed by parentheses, 
while the optional documentation are enclosed in dou- 
ble quotes. A message without arguments may appear 
with or without parentheses enclosing it, while mes- 
sages with arguments appear as a parenthesized list with 60 
the message name as its first element followed by the 
arguments. A literal data message that is passed is de- 
noted as a literal string enclosed in double quotes. 

An OOScript embodies a rule covering the interac- 
tion between the sender and the receiver during a trans- 65 
action where the sender sends a message to the receiver. 
A message may consist of a function invocation, (i.e. 
requests for action as in procedure call), data transmis- 
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sion, or both. The rule specifies which entity or entities 
are the sender and receiver, the specification of the 
conditions governing when such an interaction occurs 
and the conditions that are the results of the interaction. 
A script is a set of OOScripts covering the rules, of 
behavior of a system for a particular situation or event 
sequence. 

FIGS. 2-5 give an example of how OOScripts are 
used to provide a specification and a simulation of a 
computer login sequence. FIG. 2 is a flow chart dia- 
gram of the implementation computer sequence, FIG. 3 
is diagram showing the corresponding OOScripts used 
to implement the computer login sequence, and FIGS. 
4-5 are graphical displays of a login sequence simula- 
tion by GRAS. 

A computer 400 initiates the computer login sequence 
by sending a "send-login" message 405 to a terminal 410 
(action block 210). The corresponding OOScript for the 
initiation step is shown as OOScript 310 in FIG. 3. The 
terminal 410 responds to the "send-logM)" message 405 
by displaying a login prompt message 415 to a user 420 
(action block 220 and OOScript 320). The user 420 
responds to the login prompt message by entering his 
login name on the terminal keyboard 425 (action block 
230 and OOScript 330). The next step of the sequence is 
dependent upon the level of detail of the GRAS simula- 
tion. As previously described, the OOScript identifier 
allows multiple levels of detail. More detailed levels 
show more in-depth steps of a scenario for more sophis- 
ticated users, whereas less detailed levels show a more 
high-level overview simulation. If the level of detail is 
determined to be "1" (test 240), two lower-level steps 
are simulated (FIG. 5) before the next level 4 *0 M step is 
simulated. If the level of detail is "1" (test 240), the 
terminal 510 transmits the user keyboard entry 525 to 
the computer 500 via a loginname data message 535 
(action block 245 and OOScript 340). The computer 500 
then sends the terminal 510 a message 545 to initiate a 
password entry procedure with the user 520 (action 
block 247 and OOScript 350). The next step of the simu- 
lation is the same for both level 0 and level 1 . FIG. 4 
will be referred to for the simulation. The terminal 410 
sends a "password prompt" message 435 to the user 420 
(action block 250 and OOScript 360). The user 420 then 
enters his password on the keyboard, thereby sending 
the password data 445 to the terminal 410 (action block 
260 and OOScript 370). The GRAS system next deter- 
mines whether the simulation is level of detail °0" or 
"1" (test 470). If the level of detail is "0 M , the simulation 
is ended (action block 280), however, if the level of 
detail is "1" (refer to FIG. 5), the terminal 510 sends a 
password data message 575 to the computer 500 (action 
block 275 and OOScript 380). The simulation is then 
ended. 

It is to be understood that the above description is 
only of one preferred embodiment of the invention. 
Numerous other arrangments may be devised by one 
skilled in the art without departing from the scope of 
the invention. The invention is thus limited only as 
defined in the accompanying claims. 

I claim: 

1. A method practiced in a computer system of in- 
teractively creating specifications for a computer pro- 
gram, comprising: 
wherein an actor comprises data and procedures for 
manipulating that data, wherein said data of an 
actor comprises a knowledge base, comprising a 



03/13/2004, EAST Version: 1.4.1 



5,247,651 

51 52 

series of logical assertions, and a history of changes 7. The method of claim 6 wherein said reversing 

to said data and said logical assertions; comprises sequentially deleting said results of said simu- 

responsive to receipt of actor data, receivable via an lation. 

input device, specifying actors for use in a plurality 8. The method of claim 1 wherein said simulating said 

of tape programs and storing data for said actors, 5 operational steps comprises: 

wherein said specifying comprises creating new automatically identifying decision choices for which 

actors, selecting previously created actors, and a program path has not been specified, 

modifying actor data; 9. The method of claim 1 further comprising: 

wherein a tape program comprises a set of actors and responsive to receipt of entry points via said input 

a set of rules of behavior between actors of said set; 10 device, wherein said entry points are points in said 

responsive to receipt of specification data for opera- plurality of tape programs of receipt of information 

tional steps of a plurality of tape programs, receiv- from other program specification systems, storing 

able via said input device, storing for subsequent data identifying said entry points, 

execution communications among said actors, rela- 10. The method of claim 1 further comprising: 

tionships among said actors, logical or arithmetic IS constructing a tape program comprising a plurality of 

computations for said actors, and decision points rules, wherein each of said plurality of rules speci- 

for said plurality of tape programs; and fies at least one of: communications among actors, 

thereafter executing steps of a first tape program, relationships among actors, logical or arithmetic 

responsive to receipt of a decision choice via said computations for actors, and decision points for 

input device, said executing comprising: 20 actors. 

simulating ones of said operational steps upon the 11. The method of claim 10 further comprising: 

occurrence of predetermined conditions for said combining a set of tape programs into a single, com* 

ones of said operational steps; and posite tape program for execution of a new group 

storing results of said simulating; of tape programs. 

wherein said simulating comprises at least one of the 25 12. The method of claim 11 wherein said combining 

steps of executing communications among said comprises: 

acton, asserting relationships among said actors, executing a set union of said plurality of rules, 

executing a logical or arithmetical computation for 13. The method of claim 1 wherein each of said actors 

said actors or requesting input of a decision choice. comprises a data set, and wherein said simulating fur- 

2. The method of claim 1 wherein said executing a 30 ther comprises: 

first tape program comprises all of the steps of execut- checking whether an actor's data is sufficient to exe- 

ing communications among actors, asserting relation* cute said ones of said operational steps, 

ships among actors, and executing logical or arithmeti- 14. The method of claim 13 further comprising: 

cal computations for said actors. notifying a user of insufficient actor data. 

3. The method of claim 2 wherein said executing a 35 15. The method of claim 13 wherein said data set 
first tape program further comprises the step of request- comprises a history database of changes made to actor 
ing input of a decision choice. data, and wherein said storing results comprises storing 

4. The method of claim 1 wherein said input device is changes to said actor data in said history database, 
for specifying a graphical display, and wherein said 16. The method of claim 15 further comprising: 
simulating ones of said operational steps further com- 40 changing a graphical display of an actor responsive to 
prises: a change in said actor's history database. 

graphically animating ones of said ones of said opera- 17. The method of claim 16 wherein a plurality of 

tional steps. graphical displays correspond to a plurality of views. 

5. The method of claim 1 further comprising: 18. The method of claim 1 wherein a plurality of 
responsive to receipt of an instruction, received via 45 levels of simulation are available, and wherein a differ- 

said input device during said simulation of said ent set of simulation levels may be specified for each 

ones of said operational steps, stopping said Simula- simulation, further comprising: 

tion after simulating one of said operational steps; identifying for each operational step a level of simula- 

responsive to receipt of input data via said input de- tion; and 

vice, storing additional actors or additional opera- 50 when storing results of one of said operational steps, 

tional steps; and storing said results of said operational step at its 

responsive to another instruction received via said appropriate level of simulation, 

input device, resuming said simulation of said oper- 19. The method of claim 18 wherein a plurality of 

ational steps, including said additional actors or levels of display are available, and wherein each of said 

additional operational steps. 55 levels of display corresponds to a level of simulation, 

6. The method of claim 1 further comprising: further comprising: 

responsive to receipt of an instruction, received via identifying for each operational step a set of levels of 

said input device during said simulation of said display; and 

operational steps, sequentially reversing said simu- when executing a tape program, displaying results 
lation of said operational steps and stopping said 60 only for those operational steps which are at or 
reversing after reversing a particular one of said below a level which is a member of the set. 
operational steps; 20. The method of claim 1 wherein the simulation of 
responsive to receipt of input data via said input de- one of said operational steps of said tape program corn- 
vice, modifying said particular one of said opera- prises: 

tional steps; and 65 sending a symbolic message from one actor to an- 

responsive to another instruction received via said other, 

input device, resuming said simulation at said par- 21. The method of claim 20 wherein each actor com- 

ticular one of said operational steps. prises a set of data, wherein said simulating comprises: 
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changing an actor's data as a part of simulating an 
operational step, wherein the changing comprises 
adding or removing attributes of the actor. 

22. The method claim 21 wherein the changing com* 
prises changing as a function of existing actor data and 
message data received by the actor. 

23. The method of claim 1 wherein the occurrence of 
said predetermined condition trigger the simulation of 
two or more of said operational steps concurrently, 
further comprising: 

if any actor is common to said concurrent operational 
steps, ensuring that other actors accessing data of 
the common actor do not access the same data at a 
same time. 

24. The method of claim 23 wherein said ensuring 
comprises: 

before simulation of one operational step, delaying 
from a time of another operational step for a com- 
puted prespecified time. 

25. The method of claim 23 wherein said ensuring 
comprises: 

delaying simulation of a first operational step until a 
second operational step has been simulated. 

26. The method of claim 23 further comprising: 
executing a called tape program as part of execution 

of a calling tape program, wherein a tape program 
comprises a plurality of tape programs; and 
returning to said calling tape program following the 
execution of said called tape program. 

27. The method of claim 23 further comprising: 
simulating a subset of a second tape program after 

simulation of a first operational step of a first tape 
program and prior to stimulation of a second oper- 
ational step of the first tape program. 

28. The method of claim 23 further comprising: 
removing a subset of a first tape program for subse- 
quent reuse in another tape program. 

29. The method of claim 1 wherein said simulating 
further comprises: merging two or more actors. 

30. The method of claim 29 wherein said merging 
comprises changing the identification of a first actor to 
the identification of a second actor. 

31. The method of claim 29 wherein said merging 
comprises combining a first actor and a second actor 45 
into a third actor, wherein said combining comprises: 

assigning actor communications data of said first 

actor and said second actor to said third actor; and 

at least one of the steps of: 
assigning actor attribute data and actor relationship 

data of said first actor to said third actor; 
assigning actor attribute data and actor relationship 

data of said second actor to said third actor; 
assigning a selective combination of actor attribute 

data and actor relationship data from said first 

actor and said second actor to said third actor; and 
assigning actor attribute data and actor relationship 

data of said first actor and said second actor to said 

third actor. 

32. The method of claim 1 wherein said actors com- 
prise frames, and wherein relationships between said 
frames are maintained using dual links, further compris- 
ing: 

storing a self description of one of said frames, 65 
wherein said self description is independent from 
the computer environment where said one of said 
frames is defined. 
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33. The method of claim 32 wherein a frame inherits 
a plurality of attributes and a plurality of relations from 
its parents. 

34. The method of claim 1 wherein a plurality of 
simulated views are available, and wherein a different 
set of views may be specified for each simulation 
wherein each operational step belongs to one or more 
views. 

35. A method practiced in a computer system of in- 
teractively creating specifications for a computer pro- 
gram, comprising: 

wherein an actor comprises data and procedures for 
manipulating that data, wherein said data of an 
actor comprises a knowledge base, comprising a 
series of logical assertions, and a history of changes 
to said data and said logical assertions; 

responsive to receipt of actor data receivable via an 
input device, specifying actors for use in a plurality 
of tape programs and storing data for said actors, 
wherein said specifying creating new actors, select- 
ing previously created actors, and modifying actor 
data; 

wherein a tape program comprises a set of actors and 
a set of rules of behavior between actors of said set; 

responsive to receipt of operational steps receivable 
via said input device, storing for subsequent execu- 
tion communications among said actors, relation- 
ships among said actors, logical or arithmetic com- 
putations for said actors, and decision points for 
said plurality of tape programs. 

36. In a system containing stored actor data and 
stored specification data for operational steps of a plu- 
rality of tape programs, a method of testing said stored 
actor data and stored specification data for operational 
steps, comprising: 

wherein an actor comprises data and procedures for 
manipulating that data, wherein said data of an 
actor comprises a knowledge base, comprising a 
series of logical assertions, and a history of changes 
to said data and said logical assertions; 

executing a first program of said plurality of tape 
programs responsive to receipt of a first decision 
choice, receivable via an input device, said execut- 
ing comprising simulating operational steps of said 
first program upon the occurrence of a predeter- 
mined condition for each operational step; and 

wherein a tape program comprises a set of actors and 
a set of rules of behavior between actors of said set; 

storing results of said simulating; 

wherein said simulating comprises at least one of the 
steps of executing communications among actors, 
asserting relationships among actors, executing a 
logical or arithmetical computation for actors or 
requesting input of a decision choice. 

37. A computer program specification system com- 
prising: 

wherein an actor comprises data and procedures for 
manipulating that data, wherein said data of an 
actor comprises a knowledge base, comprising a 
series of logical assertions, and a history of changes 
to said data and said logical assertions; 

means, responsive to receipt of actor data, receivable 
via an input device, for specifying actors for use in 
a plurality of tape programs and for storing data for 
said actors, wherein said specifying comprises cre- 
ating new actors, selecting previously created ac- 
tors, and modifying actor data; 
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wherein a tape program comprises a set of actors and 
a set of rules of behavior between actors of said set; 
means, responsive to receipt of operational steps re- 
ceivable via said input device, for storing for subse- 
quent execution communications among said ac- 5 
tors, relationships among said actors, logical or 
arithmetic computations for said actors, and deci- 
sion points for said plurality of tape programs. 
38. A computer program specification testing system 
containing stored actor data and stored specification 10 
data for operational steps of a plurality of tape pro- 
grams, comprising means for testing said stored actor 
data and stored specification data for operational steps, 
wherein said testing means comprises: 
wherein an actor comprises data and procedures for 15 
manipulating that data, wherein said data of an 
actor comprises a knowledge base, comprising a 
series of logical assertions, and a history of changes 
to said data and said logical assertions; 
means for executing a first of said plurality of tape 20 
programs for evaluating the consistency of a speci- 
fication, responsive to receipt of a first decision 
choice, receivable via an input device, said execut- 
ing comprising simulating operational steps of said 
first tape program upon the occurrence of a prede- 25 
termined condition for each operational step; and 
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wherein a tape program comprises a set of actors and 
a set of rules of behavior between actors of said set; 

means for storing results of said simulating; 

wherein said simulating comprises at least one of the 
steps of executing communications among actors, 
asserting relationships among actors, executing a 
logical or arithmetical computation for actors or 
requesting input of a decision choice. 

39. The system of claim 38 further comprising: 
means, responsive to receipt of an instruction, re- 
ceived via said input device during said simulation 
of said operational steps, for sequentially reversing 
said simulation of said operational steps and for 
stopping said reversing at one of said operational 
steps. 

40. The system of claim 39 further comprising: means, 
responsive to receipt of input data via said input device, 
for modifying said one of said operational steps. 

41. The system of claim 40 further comprising: means, 
responsive to another instruction received via said input 
device, for resuming said simulation at said one of said 
operational steps. 

42. The system of claim 39 wherein. said sequentially 
reversing means comprises means for sequentially delet- 
ing results of simulation of individual executed steps. 

***** 
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